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1. INTRODUCTION 



This report documents the Software Partitioning Schemes for the 
Advanced Simulation Computer Systems Study performed by Teledyne Brown 
Engineering (TBE) under Contract No. F33615-78-C-0013 for the Air Force 
Human Resources Laboratory (AFHRL) . The report contains five sections. 
Section 1 introduces the study objectives, background, approach, and re- 
sults. Section 2 defines the software partitioning problem environment, 
partitioning goals, and alternative approaches. Section 3 presents the 
technical details of the resultant software partitioning algorithm 
developed and manually demonstrated under this contract. Section 4 
addresses implementation considerations and recommends a schedule of 
tasks for algorithm automation verification and validation. Section 
concludes with a brief recapitulation of the study findings, related 
work, and areas of further study. 



1.1 OBJECTIVES 

The overall objective for this study was to design software 
partitioning techniques that can be used by the Air Force to partition a 
large flight simulator program for optimal execution on alternative mul- 
tiple processor configurations. In particular, the Air l^orce needs a 
software partitioning algorithm for use in conceptualizing, manipulat- 
ing, and evaluating candidate flight trainer computational designs. 
Major design objectives pursued by TBE in deriving the software parti- 
tioning algorithm included emphasis on potential automated steps, manual 
feasibility demonstration, and recommended implementation steps for its 
use by the Air Force. 



1.2 BACKGROUN D 

It has been evident for some time that significant increases in 
computer system performance may be realized by using two or more smaller 
processors connected in parallel, as opposed to one large processor. 
This concept has been utilized in many real-time flight simulators where 
each of several computers performs a specific task. Future tirends are 
toward further expansion of this concept to include m t only tasks that 
may be executed in parallel but also tasks that must execute serially 
because of temporal relationships. This causes many multiple processor 
configurations to be applicable to flight training simulators and com- 
plicates the problem of allocating the software among the processors. 

Typically, the design of a computer system is an iterative pro- 
cedure. Certain portions of the hardware and software can be designed 
independently, but the remaining portions must be designed interac- 
tively. With the rising cost of software, it has become more and more 
important to know the effect of computer hardware desi^i on the design of 



the software as well as the effect of the software design on the selec- 
tion and interconnection of the hardware to develop the optimum design 
for the computer system. 

This study has pursued the development of an algorithm that will 
facilitate the partitioning of both parallel and sequentially dependent 
tasks to a given hardware configuration. The algorithm has the potential 
of being automated. 



1.3 APPROACH 

This study was comprised of three phases: Phase I - Literature 
Search, Phase II - Simulator Analysis, and Phase III - Algorithm Design 
and Demonstration. This three-phased approach provided a logical 
sequence of research and analysis that resulted in the delineation of the 
partitioning technique presented in this report. 

The Phase I literature search focused on current documentation, 
in two major technical areas. The first area concerned flight training 
simulator computational subsystem designs. The second area addressed 
software partitioning schemes for allocation of parallel and serial 
application tasks to advanced multiple processor configurations. 

The Phase II effort was subdivided into two parts. The first 
part was the analysis of literature collected to properly identify the 
software partitioning goals with respect to flight training simulator 
designs. The second part was the selection and expansion of the specific 
approach for the techniques to be applied in the algorithm design to 
achieve the design goals. Partitioning approaches considered included 
manual allocation schemes, real-time dynamic task allocation schemes, 
and a mathematical goal program statement of the allocation problem. The 
mathematical goal program model approach was selected because of its 
potential for systematically obtaining optimal partitions and related 
quantitative measures in an automated mode, which are responsive to 
alternative candidate design features. The features and measures that 
can be modeled are described in Section 3 in terms of the mathematical 
model, algorithm design, and algorithm feasibility demonstration. Model 
measures include task sizing and timing; processor utilization; memory 
storage, retrieval, and sizing; and real-time task constraints and 
relationships . 

Some problems were encountered in pursuing the Phase III design 
to implement the mathematical goal program model when allocating a large 
number of tasks and data blocks to a large number of processors, memo- 
ries, and peripherals comprising the candidate configuration. It became 
evident that a heuristic goal program algorithm needed to be designed 
that interfaces with a linear program optimizer to obtain "good" task 
partition allocations for large partitioning problems. TBE's Input/ 
Output Requirements Language (lORL) supplemented with flowcharts was 
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used to delineate the algorithm design and provide the steps for perfo 
ing a manual demonstration of the algorithm's feasibility. 



1.4 RESULTS 

One of the most important results of this study was a mathemati- 
cal model defining partitioning parameters and measurements. From these 
parameters, a set of guidelines has been recommended for the establish- 
ment of a centralized automated flight training simulator computational 
design data base repository for the Air Force. Tnese design parameters 
address five major areas, including flight training simulator computa- 
tional interface requirements, baseline software task/data descriptions 
(independent of hardware implementation), candidate hardware configura- 
tion specification, a technology data base, and (most important) design 
evaluation user interface data options. These parameters along with the 
partitioning mathematical model provide steps for the implementation of 
an automated partitioning algorithm for real-time simulators. Detailed 
recommendations for algorithm implementation are provided in Section 4. 

Section 5 expands TBE's findings, including related aspects of 
our Advanced Multiple Processor Configuration study contract encompass- 
ing areas for further research and development. In the multiple proces- 
sor area, the impact of heterogeneous processor configurations and 
potential reconfiguring capabilities is currently being investigated. A 
major area for future study is the impact of higher order architectures 
on partitioning allocation. 
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2. SOfTOARE PARTITIONING 



To develop the software partitioning algorithm design goals, TBE 
addressed the definition from both general system software design and 
particular flight training simulator software design viewpoints. This 
section supplies the basic definition of the software partitioning 
environment, the design goals selected for flight training simulator 
software partitioning features, and alternative approaches considered 
during this study. 

2.1 PARTITIONING ENVIRONMENT 

To fully appreciate the software partitioning environment and 
its associated steps, one must first examine its relationship with the 
system life cycle. Then, flight training simulator system life-cycle 
peculiarities must be considered. The questions posed by this study in 
both t^ese areas concerned the identification of the software applica- 
tion cask features that are peculiar to advanced real-time simulation 
computational systems and that influence the software design partition- 
ing process. The system and flight trainer life cycles are now described 
for the general system, followed by a description of the flight training 
simulator software partitioning features. Emphasis was placed on iden- 
tifying software features that characterize an optimal partitioning 
scheme and that account for alternative candidate configurations and 
provide partitions that meet real-time load balance constraints. 

2.1.1 System Life Cycle 

Figure 1 depicts the major phases of a system development 
effort. The development phases that directly relate to or influence 
software partitioning include subsystem interface requirements, sub- 
system functional specification, and subsystem detailed design. In 
addition, during the operational maintenance of the system, any changes 
that are deemed necessary (to either correct for a design deficiency or 
oversight, or to implement an expanded capability) imply that a reparti-- 
tioning of tasks may be needed to accommodate the required change. This 
phasing relationship to partitioning holds for any system, whether it is 
an aircraft, computer center, air defense system, or a flight train- 

ing simulator system. 

For purposes of this study, the detailed design phase was 
selected as the major area where software partitioning parameters become 
known. Prior to this phase, a system partitioning is generally performed 
to denote the major subsystems and their respective interface functions. 
After the detailed design phase, actual hardware is procured from which 
prototype build implementation is initiated. Therefore, the detailed 
design phase has the greatest influence on mapping software tasks to 
hardware and vice versa. 
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Figure 1. The system life cycle addresses partitioning at subsystem, 
function, and detailed design phases for new and/or modi- 
fied system development efforts. 
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The design of a multiple computer system traditionally has begun 
with the hardware selection. Once the computer system has been selected, 
the development of software begins. During development and even after 
the system is installed in the field, there are various modifications to 
both the hardware and the software. Because software has traditionally 
lagged the hardware development activities, the hardware has had a 
direct influence on software partitioning. As the details of the soft-- 
ware tasks become known, projected hardware resources are typically 
found to be inadequate, which necessitates the acquisition of additional 
processors and/or memories to meet system interface requirements. A 
software partitioning algorithm must be able to address software appli- 
cation design parameters, which are independent of a particular hardware 
configuration, to permit a variety of design tradeoffs to be evaluated 
for alternative candidates prior to the exact configuration selection. 

Once a system enters the operational phase, maintenance becomes 
the prime cost factor (indeed, maintenance cost is the largest cost of 
the system life cycle). Change and configuration controls are necessary 
for a system or subsystem of any significant size. As technology 
advances, new software and hardware architectures may need to be imple- 
mented. A tradeoff must be made to decide whether to convert or totally 
redesign existing software. A software partitioning algorithm should 
provide useful information regarding allocation of current baseline 
software design tasks to the new or modified hardware architecture. As 
with design development, software partitioning in the operational main- 
tenance phase addresses the design details of any proposed changes. 

The key factor for flexible software partitioning (from the sys- 
tem life-cycle viewpoint) is the ability to define software design 
attributes in terms of the dependent application software task/data flow 
relationships. The software attributes should remain independent of, 
but be mappable to, a particular processor architecture. The prolifera- 
tion of requirements languages (RLs) and higher order languages (HOLs) 
is a testament to this emerging .philosophy in the DOD community. The 
distinction between an RL and an HOL is that RLs are not currently 
automated to the extent of target machine code generators for the RL. An 
HOL such as JOVIAL, HAL-S, or PL-1 supports interpretation, data manage- 
ment, and cod generation from machine-independent HOL source code to an 
intermediate level language that can then be specifically translated to 
any one of the languages supported by different target machines. Once 
the tasks have been defined in a suitable RL and HOL, the problem still 
exists as how they can best be partitioned or allocated to the candidate 
architecture. Once allocated, the resulting partition should be evalu- 
ated in terms of predicted performance and cost/risk assessments by a 
software partitioning model. Iterative feedback from this performance 
evaluation model can then be used to perturb the partition based on 
performance penalties to derive a well-balanced software execution 
sequence . 
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2.1.2 Flight Trainer Life Cycle 



In addition to problems associated with the general system life- 
cycle environment, the simulation training system environment offers 
special considerations and problems with respect to software partition- 
ing. Aircraft systems are continuously being upgraded, and this causes 
changes to training requirements. Manual interfaces change when new or 
modified weapons systems, embedded onboard computer systems, and opera- 
tional tactical policy changes are introduced. These problems are 
really no different from problems encountered during the maintenance 
phase of the actual system. The key issue is when and how actual system 
changes are received, evaluated, and introduced into the training 
requirements. 

Actual system test and perfoxrmance measurement tools can and 
should provide useful inputs for simulator training software required to 
support the new/modified devices. In the case of embedded computer sys- 
tems, simulated training scenarios could provide additional reliability 
tests of the actual onboard computer systems as well as the prime goal of 
training personnel. As a result of these considerations, the partition- 
ing algorithm should facilitate modular design definition input changes 
and permit new technology configurations to be introduced as needed to 
support a given evaluation. This should also include the ability to fix 
allocations of certain functional tasks, such as a set of onboard com- 
puter tasks, while permitting others to be allocated by the partitioning 
algorithm. 

AFHRL supplied a benchmark problem and the detailed design docu- 
ments and source code listings from the Advanced Simulator for Under- 
graduate Pilot Training (ASUPT, now known as Advanced Simulator for 
Pilot Training (ASPT)). These documents were analyzed to obtain esti- 
mates on the complexity and sizing of flight simulator software parti- 
tioning. This analysis identified 50 major application (both real-time 
and support) tasks (some of which would be duplicated to support multiple 
training stations, instructor consoles, weapon systems, and aircraft 
models). The results of this analysis were presented at an interim 
briefing. 

It should be noted that a task is related to the application. 
Its ultimate operational realization may be software, firmware, hard- 
ware, or a combination of these, depending on the selected design config- 
uration. Tiie tasks being considered for the partitioning algorithm are 
related to the computational subsystem of real-time flight training sim- 
ulators. 

Further analysis revealed that the trainer computational sub- 
system is really comprised of a set of smaller functional subsystems, 
such as simulator facility control, visual computational support, and 
simulated aircraft mathematical models; thus, the number of processors 
and number of tasks for which selected software functions are being 



allocated is reduced to approximately 30 tasks to three processors using 
a common, shared multiport memory. In summary, flight trainer computa 
tional configurations have both a functional partitioning of processors 
and a task partitioning within each functional processor group, 

2.2 DESIGN GOALS 

Software partitioning of tasks to alternate candidate multiproc- 
essor configurations must be a systematic process based on measurable 
evaluation goals. The selected design goals for the partitioning algo- 
rithm developed are as follows: 

(a) with software system task flow inputs given, partition 
tasks to a user-^specif ied multiprocessor hardware configu- 
ration subject to input constraints 

(b) Identify interdependencies among the tasks that require 
communication 1 inks 

(c) Incorporate dynamic performance evaluation feedback to 
determine the best partition to preclude system deadlocks 
and account for critical path task precedence orderings 

(d) Provide a means of balancing the processing load as a func- 
tion of processor utilization, which is evenly distributed 
among the processors such that no one processor is satu- 
rated while others remain idle for appreciable periods of 
time 

(e) Provide cross reference of task(s) assigned to each proces- 
sor and processor(s) assigned to each task 

(f) List critical constraints when a valid partition is not 
obtainable 

(g) Provide a development cost estimate as a function of task 
sizing and instruction mix, which is related in terms of 
assigned candidate processor language compilers and debug 
tool measures. 

In deriving this set of goals j several issues have been dis- 
cussed pertaining to the evaluation environment in which the partition- 
ing algorithm is to operate. The baseline set of questions was: 

(a) At what point( s) in the system development cycle is the 
algorithm to be used? 

(b) What timeframe and computer resources are anticipated for 
candidate evaluations ? 
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(c) To what extent will the system requirements be formatted? 
In what format? 

(d) To what extent will the alternative candidate design con- 
figuration be documented? In what format? 

; The answers to these questions relate directly to the level of 
softv;are partitioning and types of system parameters that can be 
modeled, allocated, and measured. In summary, there are no definitive 
answers to these questions since each flight trainer evaluation tends to 
be tailored to specific needs. This does not mean that systematic 
methodologies and standards do not exist, but they do differ from one 
project to another. The potential use of an automated partitioning 
algorithm will require systematic collectiuii and development of flight 
trainer requirements, software specifications, and candidate configura- 
tion inputs. This contract has concentrated on the definition of parti- 
tioning algorithm logic in terms of design inputs which are transformed 
via technology data and user evaluation options to assist and assess the 
partitioning of tasks for a given candidate configuration. 

2.3 ALTERNATIVE APPROACHES 

Software partitioning to date has been primarily a manual proc- 
ess based on experience gained in development of previous flight simula- 
tors. The designer community continually evolves and improves partition 
allocations using projected resource requirements and implementing the 
partition to see how well it performs. In some cases, real-time alloca- 
tion is determined by a master computer using a predefined assignment 
scheme that incorporates certain dynamic application considerations. 
These schemes, whether manual or partially preprogrammed controlled, are 
not easily automated, since they generally require that a specific sys- 
tem allocation be implemented for a given configuration. Manual projec- 
tions are limited to a few alternatives for a given type of configura- 
tion, but they must be redone for alternative configurations. 

In surveying potential automated models to meet the design 
goals, the basic problem to be solved is one of distributing the software 
system tasks and related data blocks to a candidate hardware architec- 
ture network such that a representative stressing sinnilation load is 
handled. In general, this type of problem is typical of mathematical 
programming problems addressed in an operations research (OR) environ- 
ment. Within this field, there are a variety of algorithms. The follow- 
ing are some of the more familiar: 

1. Transportation problem of product transport from production 
locations to warehouses and customer distribution centers to 
meet customer demand at minimum cost. 
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2. 



Traveling salesman optimal route determination to service 
customers 



3. Knapsack packing of items required for a camping trip to be 
distributed evenly among campers 



4. Capital budgeting problem of choosing among independent 
investment alternatives to maximize return subject to cur- 
rent investment fund constraints 



5. Machine shop production scheduling to meet product demand 
deadlines with minimum machine restructure between jobs and 
given employee mix. 



The software partitioning problem has attributes similar to each of 
these . 

In the case of the software partitioning problem, a descriptive 
statement of the model is as follows: 



1. Find a partition that best satisfies alternative evaluation 
priority functions : 

u. Balance the processing load among the processors 

b. Balance the memory storage utilization 

c. Minimize development costs. 

2. Subject to: 

a. Real-time task resource requirements 

b. Predicted performance simulation feedback. 

When defining a software task partitioning model, a number of 



factors must be considered. The model can very quickly get out of hand 
in terms of size for current optimization techniques. Thus, the model, 
design developed under this contract restricted itself to a static allo- 
cation problem that is mathematically stated as a linear goal program 
problem in Section 3.1. It is static in that it is a generalization of 
the real-time application tasks to be allocated to a given candidate 
configuration. In this sense it is not a dynamic real-time allocation 
algorithm. The static model is very useful in the candidate design 
evaluation mode, since many numbers are based on predicted task sizing 
and timing plus anticipated computation iteration frequencies to support 
given training loads. The static model permits average to worst-case 
growth analysis in a systematically controlled evaluation environment, 
which provides the means to ensure a complete design description has been 
input and independently provides a measure of processor utilization, 
memory utilization and predicted software development cost. 
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Even in the static model environment, optimization data base 
sizing and numerical roundoff problems are encountered for evaluation of 
a computational system involvipg tauch more than three processors, 20 
tasks, 40 data blocks, and four, memories. Specific sizing is addressed 
in Section 3.2. For this rear.on, a heuristic model has been designed. A 
heuristic model is a means of limiting computations to a logical sequence 
of iterative improvements via allocation tradeoffs until a certain 
objective level is either found to be feasible or a bottleneck has been 
isolated. 

This section has discussed partitioning considerations. The re- 
sultant algorithm design details are highlighted in Section 3. Imple- 
mentation considerations are given in Section 4. Section 5 incorporates 
areas for further research with respect to optimizer techniques and data 
base selection. 
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3. IViO^I DEVELOPMENT 



Software partitionir . devr;lopnient is presented from three 

different technical viewpoin .li?- section, including the mathemati- 

cal definition, the detailed i highlights, and a feasibility demon- 

stration synopsis. The mo expressed in generic computational 

system terms where the major onents are tasks, data blocks , proces- 

sors, and memories that are partitioned to service an external baseline 
load environment. The mathematical model definition delineates all the 
parameters and the basic relationships that must be satisfied for a valid 
partition. It also provides a statement of objective functions that 
permits optimization of the partition when the basic relationships are 
found to have a feasible solution (i.e., a feasible partition). 

The algorithm design highlights are presented here in terms of 
the systematic procedural step features with cross-references to 
detailed appendices. Appendix A provides user input information. Out- 
put report formats are provided in Appendix B. Appendix C contains the 
feasibility demonstration that emphasizes the user environment of input 
fprmul/ition, critical intermediate step results, and final output summa- 
ries. Detailed computations and design logic are enumerated in 
Appendix D. 



3.1 MATHEMATICAL STATEMENT 

This mathematical statement provides mathematical terminology 
and definitions for alternate evaluation priorities and constraint form- 
ulation based on a generic statement of a candidate configuration for 
which a set of software tasks are to be partitioned. Each mathematical 
symbol is defined when first introduced. In addition. Appendix C con- 
tains a master list of mathematical symbols and related design defini- 
tions. A special effort has been made to use a unique symbol for a giver- 
entity. It utilizes a combination of symbol definition with a combina- 
tion of linear programming and goal programming model formulation termi- 
nology. Although knowledge of these modeling and solution techniques is 
helpful, it is not essential to the understanding of the basic expression 
of the software partitioning problem model.' The solution techniques 
with respect to the software partitioning model are considered in the 
design highlights of Section 3.2. The model is now stated. 

3.1.1 Mathematical Terminology 

The mathematical model formulation permits the major decision 
variables to be enumerated in terms of a baseline software load for a 



Ignizio, James P., Goal Programming and Extensions , D. C. Heath and Com- 
pany, Lexington, Massachusetts, 1976 
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given real-time interval c. length, r. In the case of the flight 
trainer, r might be chosen to represent the maximum time permissible for 
a complete real -rime cycle. The baseline Irad could represent a 
stressing training mix of tasks and data relationships that must be 
performed to support the given trainer facility exercise; tor example, a 
two-on-one, air-zo-air, combat maneuvering situation may be selected. 
For more detailed partitioning loads, r could be selected to represent a 
specific segment of the real-time cycle to further analyze and partition 
parallel versus dependent task/data flow relationships. 

The major decision variables (outputs of the algorithm) with re- 
spect to software partitioning allocation are defined as follows: 

X == I, if task t is assigned to execute on processor p 

= 0, otherwise 

e - number of task t executions on processor p for the 

^ evaluation problem time period 

y - development cost to implement task t on processor p as 
currently partitioned 



^mfa 



I, if memory storage m contains block b 

== 0, otherwise 

h5 - number of memories where block b is stored 

a . - number of times input block i of task t is input for 
task t on processor p from memory m. 



mpto 



- number of times output block o of task t is written or 
updated by task t on processor p to memory m. 



These outputs are determined for a given set of software task and candi- 
date architecture inputs. The basic algorithm control inputs are 
denoted by: 

T - number of tasks to be allocated to processors 
P - number of processors 
M - number of memories 

B - number of distinct storage blocks to be allocated to memories 
(this includes instruction and data blocks) 



Q - number of communication links 

6 - maximum number of input and/or output blocks per task. 

The values of these parameters control the overall algorithm sizing, 
timing, and looping logic. 

The baseline task load may be represented as configuration- 
independent, processor-dependent, and memory-dependent input parame- 
ters. The configuration-independent input parameters are defined as 
follows for each task, t: 

- number of times task t is to be executed during the evalua- 
tion interval, r, for which partitioning is being done 

- maximum time limit per task t execution 

- number of distinct input blocks for task t 

yt^^ - global data block index for task t input block i 

. - percent of information irput for task t from block i 
ti 

0^ - number of distinct output data blocks for task t 

0^ - global data blcck index for task t output block o 

to ^ ^ . 

- percent of information output from task t to block o. 
to ^ ^ 

The processor-dependent task inputs are defined as follows for 
task t on processor p: 

c^ - time for task t execution on processor p 
tp 

- resource task management coefficient for task t on proces- 
sor p if time or data enabled task ( these tasks require 
periodic enablement or polling by the processor to which 
they are assigned) 

r - resource task management per task t execution on processor 
p for slaved enabled task ( these tasks are enabled by 
another task) 

d - the cost coefficient for developing task t to run on proc- 
essor p independent of allocation 

6 - the cost coefficient for resource management of task t 
^ development on processor p. 
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Section 4.2 discusses the implementation means for computing these 

values based on independent task descriptions, processor configuration, 

and a technology data base. The mathematical model assumes that these 
values are known. 

In addition to the task-to-processor allocation relationships , 
the storage allocation of blocks to memories operates on a similar con- 
cept. A master block list of distinct data and/or instruction blocks is 
independently defined and then mapped via the candidate configuration 
and technology memory parameter inputs to supply the following parame- 
ters with regard to block fa, memory m, processor p, and communication 
link q: 

t^j^ - length in bits of block b when stored in memory m 

L - length of memory m in bits 
m 

a = 1, if access from memory m to processor p exists, i.e., 
there is at least one access link q for m and p 

= 0, if otherwise 

a - bits/second transfer rate from memory m to processor p 
™^ based on statistical composite of access links for p and m 



W^^ " 1> if processor p is permitted to change contents of 
memory m, i.e., there is at least one write access link q 
from p to m 



mp 



= 0, if otherwise 

0) - bits/second transfer rate from processor p to memory m 
™^ based on statistical composite of write access links for p 
and m. 

The task relationships to these blocks are defined as part of the real7 
time constraints in Section 3.1.5. 

3.1.2 Processor Utilization and Growth Balance 

/ 

Given the mathematical tenns defined in Section 3.1.1, the proc- 
essor utilization, U , associated with a partition may be expressed as 



follows (for each processor p=l to P) 



u =-L 

P T 



E 

t=l 



(c + r ) e task computation 

tp tp tp J 

and resource 

management time 
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t M 

~: ti^T nop mti mpti 

1=1 m=l . ^ 



task input 
processing 



0 = 1 



M 



^to^ ^pAnto^mpto 
m=l ^ ^ 



task output 
processing 



tp tp 



task resource 
management 



An absolute constraint is that: 



U < 1 for p=l to P, 
P 



In other words a processor, p, cannot be more than 100% allocated. 

The objective function for processor balance may be written: 



Minimize 



P-1 



E E i"i - "i 



i=l j=i+l 



Minimize differences 
in processor loads 



It should be noted that the presence of absolute values implies a non- 
linear objective. The processor utilization balance can be mapped (via a 
ranked ordering of the U such that U^' >. U.') to a linear objective 

for a given partition. ^ ^ J 

This objective statement assumes that perfect balance is the 
ultimate or optimal partition. The candidate design being considered 
may represent only a portion of a bigger design evaluation problem. In 
this case, the use 9f certain processors may be favored, whereas others 
should not be considered- To handle this more realistic partitioning 
situation, each processor has two additional parameters, which are user- 
specified: 



- absolute upper limit for processor p's utilization 
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- goal or target limit for processor p's utilization. 



With these additional parameters, the following constraints apply: 



'G < L Goal must be 

P - P 1 

less or 

equal to the 

absolute limit. 

U < / Each processor 

P P 

must be below 
its absolute 
limit. 

The objective for the optimal partition in terms of processor utiliza- 
tion becomes: 



P-1 P 

Minimize ^ ^ (U^-G^) " (U^-GJ . 



i=l j=i+l 

This basically states that the processor utilization is in balance with 
respect to user-specified goals. In the case of a flight trainer soft- 
ware partitioning evaluation, G^ could reflect a percentage that allows 
for future growth. Thus, G^ - 0.60 reflects a 40% growth factor for 
processor p« 

The algorithm as currently designed (Section 3,2) assumes that 
an initial feasible solution is provided by the candidate design and 
utilizes a heuristic solution based on the absolute difference between 
the most heavily loaded processor and the least loaded, taking into 
account the goal growth reservation to distribute the process load. 



3.1,3 Storage Utilization and Growth Balance 

Stora 
m=l to M, as: 



Storage utilization, u^, may be expressed for each memory unit. 



u = y lS / . Sum of blocks 

m L rob rao j j • • j j 

m 0=1 stored divided 

by total memory 
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As with the processor balance formulation, storage utilization cannot 
exceed the capacity of the device. 



u < 1 for m=^l to M 
m 



In addition, storage growth balance can be established with a 
respective goal utilization, g^., and an absolute limit, 4^, for each 
memory as follows: 

M-1 M 

Minimize !S (u.-g.) - (u.-^g.) 



i-1 j-i+1 ^ ^ 



where 



m 



< ^ for m==l to M. 



m 



As with the processor utilization, the solution technique 
defined in Section 3.2 for storage utilization is bas^d on a heuristic 
driven by the most^^jised and least used memory allocations with respect to 
input goals. 

3.1.4 Development Cost 

Software development costs are. a function of task complexity and 
programming support tools available. In particular, the heterogeneous 
multiprocessor system adds another development cost concern, i.e., 
coding of a task to perform on more than one processor type. A common 
program source language significantly reduces duplicated coding efforts* 
Thus, the development cost for a given software task, t, in the model may 
be stated as: 



if 




E 




p=l 




+ rS 


X 


tp tp 


d 


tp ^tp 



one-time development 

resource manager development 
duplicate utilization. 



where 



tp 



0 for p=l 

max K. ^ . for i 
( ipt ti 



= 1 to p-1 for p>l 
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1, if an identical source language is 
available on processor i and p (i p) for 
task t 



= a technology-specified constant if differ- 
ent languages are to be used (i ^p) 

= 0, if i = p. 

If the code already exists, then 

Note that the multiplicative factor for determining y^ can be stated as 
an equivalent series of linear constraints because of Ehe zero-one vari- 
able x^ (task t is either assigned to processor p or it is not). These 
(p-1) constraints are enumerated as follows for a given task t on proces- 
sor p (for p > 1) . 



Xlpt ^tl ^tp ^ ° 

\2pt ^t2 " ^tp < 0 



\(p-l)pt ''t(p-l) ^tp " °' 

With this set of constraints, minimizing y^ in the achievement function 
ensures that y^ will assume the appropria?e maximum as defined in the 
original definition. 

The goal objective for software development cost is now stated 

as : 



T 

Minimize 



L = l 

This is basically a problem of reducing development cost. The design 
attempted to reduce development cost (Section 3.2) to be less than a user 
supplied value, p, where V represents a ballpark estimate for the total 
software development. The unit used may be man-years or dollars, depend- 
ing on units established for the technology data base (described in 
Section 4.2), which will be used to translate the task t instruction mix 
(Section 4.2) to its one-time development cost (^^p) ^or processor p» 
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The common language coefficient, \^ ^, is also a function of the tech- 
nology-processor-related data (Section 4.2) and the language factor 
selected for the task. 

3.1.5 Real-Time Task Resource Requirements 

The major constraint areas interact with the objective priority 
evaluations to further specify acceptable partitioning attributes. As a 
minimum, the following constraints apply to basic task resource require- 
ments and processor accountability : 

(a) Each task, t, must be assigned to at least one processor. 
This implies T constraints of the following: 



/ ^ > 1 for t=I to T. 

^1 

(b) If more than one processor is permitted to perform the same 
task, a resource management overhead will be allocated to 
task t processors via the processor utilization objective 
of Section 3.1.2. However, to ensure that is properly 

coupled with e^^, the following constraint must be applied: 

^ \ !t£ > 0. 
tp 

In addition, constraints must address task iteration rate and task ser- 
vice times to ensure that real-time task timing requirements are met: 

(a) Given that task t must be executed times during the 
problem time period, r, the task iteration rate constraint 
is: 



E 



tp t 



(b) If overlap of task t execution is not permitted (i.e., t 
cannot be executing on more than one processor at a time), 
the following constraint applies: 
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where S is the maximum time limit for one execution of task 
t. 

Note that if 

+ > 
tp tp t 

then e can be automatically assigned a zero value and 
deleted^from consideration. 

Task data dependencies must also be satisfied. These constraints 
include: 

(a) All data blocks associated with task input must be availa- 
ble to the processor(s) that are permitted to perform the 
task. Thus, for input block the following holds: 

M 

-x^ + as. > 0 

tp / ^ mp nix,^^ 

m=l 



for i=l to I^, t=l to T, p=l to P. 

(b) All data blocks associated with task t's output must reside 
in memory storage in, which can be updated (changed) by any 
of task t's processor(s) p. If x satisfies 

x^ + x^ =1 
tp tp 

then for a given task output, block b = 0^^, the following 
holds: 




M 
m=l 



x^ + Mx^ + m; s , - h, 

tp tp / J mp mb b 



for t=l to T, 0=1 to 0^, p=l to P. h^ represents the number 
of different memories that have duplicate copies of block 
b; thus , this constraint requires all duplicate blocks to 
be updated (see next constraint set). 

(c) Any duplicate data blocks must be held to a minimum; there- 
fore h^ may be thought of as a penalty to be added as an 
additional objective function with the following additional 
constraint: 
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> 1 (at least 1 block is in memory) 



ana 



m=l 



for fc> = 1 to B. 



Input timing must properly account for the number of task t 
executions on processor p (e ) for each task input block, 



tp 

, 1=1 to I,: ^ 
ti' t 



M 

e*. - V a . = 0 
tp ^ mpti 

m=l 

a . ) 

and ^ s ; ^ > 0 for m=l to M 

mp m<.^ . 
^ ti t 

are used to ensure that ^ . is available on memory m. 

ti 

Output timing must account for the number of task t execu- 
tions on processor p (e ) for each task output block, ^ 
o=l to 0^: ^ 



£p mpto 



N (i ~ s ) < 0 



and 



mp mO 



to 



w 



mpto 



> 0 for m=l to M 



are used with a corresponding achievement function that 

minimizes w to ensure that' all duplicate blocks of ^. 

, ^ -mpto to 
are updated* 
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3.1.6 Performance Simulation Feedback 



Sections 3 . i . 2 through 3.1.5 comprise the fundamental model 
objectives and constraints that must be set in terms of a valid static 
allocation of tasks. Performance bottlenecks detected by the simulation 
mode being developed under separate contract (No. F33615-79-C-0003) 
will add additional constraints and/or modify coefficients. In particu- 
lar, the data transfer objective coefficients for given interfaces 
between a memory and a processor may be readjusted to penalize use of 
certain processors for a given task and/or memories for certain data 
block allocations. 

A stronger set of timing constraints may be required for depend- 
ent software task threads • A task thread., F^, may be defined as a group 
of serially dependent tasks with the following notation: 

k 

where f, indexes one of the T tasks. In general, task f^ must have 
executed^ , percent before task F^ can be enabled. Thus, the tasks 
defined as a^thread are not permitt^ to run simultaneously in parallel 
processors. This constraint may be written for each thread k as follows: 

p=i 

for k~l to K, and represents feedback timing for thread K, A further 
assumption is that if task t is an element of a software thread, F^, then 
task t may not be an independent task or an element of another task 
thread. If a task is required in more than one way, it can be defined as 
a group of different tasks for partitioning purposes. 

In general, these threads represent critical system task path 
flow bottlenecks as determined by the performance simulation of a given 
partition allocation. The algorithm introduces new or revised con- 
straints until one of the following conditions exists: 

(a) Satisfactory solution found 

(b) Infeasible condition identified 

(c) Maximum feedback iterations performed. 

The current solution state is to be saved and/or printed for future 
evaluation as requested by the user evaluator. 



< minimum {'^ , T, } 
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3.2 ALGORITHM DESIGN HIGHLIGHTS 



There are many mathematical program techniques, including both 
linear and nonlinear optimizers and h":uristics. The partitioning model 
requires integer solution values that immediately classify it as a non- 
linear global optimization problem even though the model itself consists 
of linearly expressed objectives and constraints. In addition, two of 
the three achievement priority functions (i.e., balance the processor 
load and balance memory storage) are nonlinear in their formulation of 
minimizing the sums of absolute differences. These nonlinear goals 
combined with the goal program matrix, which is sized according to the 
parameters represented in Table 1, would be a challenge to both sizing 
and timing of commercially available mixed integer linear program models 
with a single achievement priority. 

To determine the viable design alternatives, a study of goal 
programming was made, including several military goal program applica- 
tions that have been implemented. Applications included weapon system 
slice optimization in relation to planning force analysis and a balanced 
budget allocation model for mixed project/agency funding. Both of these 
applications interface goal programming models with other analysis tools 
(such as simulation, input/output analysis, and regression analysis) to 
provide a set of automated operational evaluation tools. These 
additional tools provide a means to cross-check and supply detailed 
model data values that are used to calibrate the goal program model. Tlie 
calibrated model is then used for selected parametric studies to 
determine impact on solutions in terms of parametric margins and 
solution sensitivities. Both of |:t}ese applications utilize modified 
versions of the classical textbook multiphase goal program computer 
algorithms. A major drawback to these codes is their susceptibility to 
numeric roundoff error propagation for problems involving more than 50 
to several hundred variables and constraints. In addition to the 
numerical roundoff errors, the multiphase codes studied do not use 
dynamic core memory management. This requires the entire matrix and 
associated bookkeeping variables reside in main memory. 

In lieu of funding the development for a mixed integer goal 
program optimizer for larger problems, an alternative algorithm is the 
sequential use of a good commercially available linear program optimizer 
interfaced via a goal program driver that introduces each achievement 
one at a time. This permits continuous solution problems with up to 
16,000 rows to be handled, given adequate dynamic disc storage. Current 
state-of-the-art integer solutions are restricted to several hundred 



Ignizio, James P., Goal Programming and Extensions , D. C. Heath and 
Company , Lexington, Massachusetts , 1976 

Lee, Sang M., Goal Programming for Decision Analysis , Auerbach Pub- 
lishers, Philadelphia, Pennsylvania, 1972 
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TABLE 1. BASIC GOAL PROGRAM MATRIX SIZING 



CASE 


CONTROL PARAMETERS 


RESULTANT MATRIX 


T 


P 


B 


M 


I 


0 


VARIABLES 


ROWS 


COLUMNS 


1 


30 


2 


61 


3 


3 


2 


1,330 


1,747 


4,824 


2 


30 


3 


61 


4 


3 


2 


2,383 


3,009 


8,401 


3 


30 


3 


120 


4 


3 


3 


3,038 


3,608 


10,224 


4 


30 


3 


120 


6 


3 


3 


4,358 


4,688 


13,734 


5 


60 


4 


140 


6 


3 


3 


10,351 


12,271 


34,893 


Prob 1 


5 


2 


12 


3 


3 


3 


264 


348 


960 


Prob 2 


7 


4 


21 


6 


3 


3 


1,250 


1,642 


4,534 



Variables = B + P + M + 1 + MB + 3TP + TPM (I + 0) 



Rows = B + P + M + 1 + 2T' + 2TP (1 + I + 0) + TPM (I + 0) 

Columns = Variables + 2 (ROWS) 
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variables. The sequential use of a linear program optimizer is the 
approach recommended for further study in addressing a subset of the 
software partitioning algorithm as designed in this study. The design 
has remained independent of a specific computer optimizer code. 

Even with the sequential mixed integer linear program technique, 
the sizing of the partitioning problem (given in Table 1) is prone to 
challenge the best optimizers without some careful matrix selection gen- 
eration techniques. There are two major areas of concern: 

1. The time consumed in determination of an initial feasible 
solution 

2. Excessive iteration thrashing to determine "optimal*' integer 
solutions. 

The study of goal programming included a survey of heuristic techniques 
that can facilitate the search for improved solutions given an initial 
feasible solution. In practice, application-customed heuristic algo- 
rithms have provided an efficient means for handling and reducing the 
large solution space of alternatives to be searched. 

In the case of flight trainer candidate designs, the designers 
have an implied partition which can be used as the initial solution. The 
partitioning problem then becomes one of "Does a better solution exist 
with respect to load balance, memory balance, and development cost?" The 
incorporation of an initial solution step has been recommended as an 
implementation step requiring further study for obtaining an expanded 
evaluation capability. The current algorithm design assumes that an 
initial solution is supplied and proceeds in a heuristic manner to seek a 
better solution. 

To achieve a well-defined user evaluator interface of partition- 
ing input data, a customed heuristic goal program drivtsr, and solution 
summary capabilities , the Partitioning Algorithm for Software Systems 
(pass) has been designed emphasizing the four major processes denoted in 
Figure 2; 

1. User input interface and processing referenced as PASSl 
2* Basic partitioning algorithm referenced as PASS2 

3. Augmented partitioning algorithm (PASS3) to handle dynamic 
performance prediction feedback 



' Ignizio, James P., "Solving Large Scale Problems: A Venture into a New 
Dimension," Pennsylvania State University, 1978 
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Figure 2. Major partitioning algorithm steps. 
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4. Solution summary reports (PASS4) of a given partition for 
candidate design i. 

Prior to describing each of these steps, the overall design flow of the 
steps and their interfaces is presented. 

The major external interface (exclusive of an optimizer) with 
PASS include the evaluation user and a multiprocessor configuration per- 
formance predictor simulator. The user interface considerations for 
actual implementation are expanded in Section 4, with emphasis on 
incorporating a modular , automated data repository to facilitate input 
preparation of PASSl and maintenance of current flight trainer design 
parameters with respect to given partitions (PASS4). The performance 
predictor interface is designed to interact with the Computational Per- 
formance Predictor Simulator (CPPS) being specified and designed under 
separate contract. The iterative process of determining a new alloca- 
tion (PASS3) based on performance prediction feedback is performed until 
one of the following conditions is reached: (a) satisfactory partition 
is found, (b) design bottleneck is identified, (c) maximum iterations 
have been reached. 

3.2.1 Input Processing Step PASSl 

The mathematical statement of Section 3.1 contains software, 
hardware, and combined software/hardware parameters. The design efforts 
of this study have emphasized the separation of any combined parameters 
into basic hardware and software components with the aid of technology 
data base tables and computational formulas necessary to generate the 
given "combined" parameter. Thus, all task/processor and data/memory 
parameter? are derived from independent software and hardware design 
configuration inputs (see Section 4.2). 

The specific inputs are defined in Appendix A. Figure 3 deline- 
ates the major design process flow for user input editing and computa- 
tional sequences to properly set up for the actual partitioning steps 
that follow. The design demonstration (Appendix C) provides the 
detailed computations to map the user input into the internal partition- 
ing algorithm control and lookup tables listed in Table 2. Appendix B 
provides representative report formats for the user input echo, which 
consists of the reports listed in Table 3. 

3.2.2 Basic Partitioning Algorithm (PASS2) 

This step provides the basic controls and logic for interfacing 
with the three user-ordered heuristics to determine whether an improved 
partitioning solution can be found. As mentioned in the introductory 
remarks on design in Section 3.2, the basic assumption is that an initial 
feasible (with respect to real-time constraints) partition is supplied. 
The resultant basic partitioning algorithm flow is denoted in Figure 4 as 
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TABLE 2. INTERNAL PARTITIONING ALGORITHM CONTROL AND LOOK-UP 
TABLES ESTABLISHED BY PASS 1 
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TABLE 3. USER INPUT ECHO REPOR^: THAT ARE SPECIFIED IN APPENDIX B 



FORMAT* 


REPORT TITLE 
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Hardware Component Summary 
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Data Block Summary 
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Task Summary 
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Baseline Load Summary 
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Evaluation Options/Restrictions 
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Evaluation Priorities 
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Basic Partitioning Problem Size 



Format reference to Appendix B 
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Figure 4. Basic partitioning algorithm control flow. 
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being comprised of initial solution verification, heuristic control 
table setup, and user-specified, priority-ordered heuristic executions. 

There are three basic heuristic algorithms corresponding to the 
three objectives or achievement functions: processor utiliz^ition 
(LOADBL) , memory utilization (MEMBAL) , and development cost (RDCOST) . 
Figure 5 denotes the major selection branch as being a function of the 
user-specified priority execution order GOAL (g), where g is the current 
priority level being executed. Prior to invoking the appropriate heu- 
ristic, a test is made to determine whether the basic priority goal level 
has already been achieved. If so, a return is made to proceed to the 
next priority level. 

The major features incorporated, in the design permit ranking of 
the current partition solution variables with respect to impact on the 
given priority under consideration. The following ranking definitions 
are utilized for each of the respective heuristics; 

1. For the load balance heuristic, processor p's utilization, 
U , is subtracted from its goal, 6 , to define U' = 6 - U . 
TRe resultant U' array is then ranged from high t8 low^valuis 
(i.e., those below their goal to those above their respec- 
tive goal in order of difference magnitude). The resultant 
ranked array is then used to determine whether the load is 
currently in balance, i.e., (U' - U' GTOLPU) with respect 
to a user-supplied tolerance (GTDLPU) Tor processor utiliza- 
tion. The object is to offload some of the tasks from the 
heavily utilized processors to the lighter loaded processors 
to obtain a better balance, as denoted in Figure 6. 

2. For the memory balance heuristic, the allocated memory, u^, 
is subtracted from its goal allocation, g , to define u'^ = 
Q -u . The resultant array, u' , is chen ranked (in a 
similar fashion as processor util ization; to determine 
whether the current memory allocation is in balance accord- 
ing to the user-supplied goal (u ' ^ 'm GTOLMU) . The 
objective (Figure 7) is to reallocate some of the blocks 
from the over-allocated memories to the under-allocated 
memories to obtain a better balance. 

3. The development cost is a minimization problem of individual 
task development cost. Thus, the tasks are ranked from most 
expensive to least expensive. The ranked cost array can 
then be systematically processed (Figure 8) to determine 
whether a more cost-effective solution is possible (i.e . , 
can this task be implemented on another processor in the 
candidate conf igurat ion of less development expense and 
still meet real-time constraints?). It should be noted that 
this priority is only applicable to a heterogeneous set of 
candidate processors . 
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Figure 7. Memory allocation balance heuristic. 
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For each of the heuristics, checks are incorporated to ensure 
that real-time limitations are not viola^.ed by any subsequent new 
"improved" solutions found by the respective heuristic. Design emphasis 
was placed on the order for incorporating these checks within the heu- 
ristic procedure to avoid excessive calculations when easily determined 
restrictions would prohibit exploring a given tradeoff. For example, 
when attempting to reallocate a task to another processor, only those 
processors that may perform the task are considered. To solve some of 
the more complex interrelated real-time constraints, a linear program 
statement might be studied to determine whether effective utilization of 
an optimizer would be feasible for performing the given tradeoff. The 
current algorithm incorporates a specific check of constraints as formu- 
lated in Sections 3.1.5 and 3.1.6. 

The heuristic driver continues at each priority level until it 
has exhausted its systematic exchange tradeoff search for an improved 
measurement. The three priority levels are executed in the order as 
specified by the user evaluation priority inputs of PASSl. The basic 
computational and logical sequence flows for each of the three priority 
levels are denoted in Figures 6, 7, and 8, respectively. 

3.2.3 Augmented Partitioning Algorithm (PASS3) 

This step is an expansion of the PASS2 processes with emphasis on 
resolving identified performance bottlenecks of the following types: 

1. Cycle or thread timing is not sufficient for real-time 
system response. 

2. Specific candidate component (i.e., processor, memory, com- 
munication link) utilization is unacceptable. 

The basic process decision flow is depicted in Figure 9. 

Recognizing that manual user evaluation ins igh t may help expe- 
dite the search for an improved partitioning, process PA 3100 facili- 
tates the option that the current allocation can be manually modified. 
Once any modifications have been processed, the performance data are 
processed via PA 3200 to readjust coefficients and to set up additional 
constraint generation controls. The new constraints are then con- 
structed and their basic impact on the current partition is assessed in 
terras of solution feasibility. Each performance bottleneck is processed 
individually, in a predetermined order of criticality during this pro- 
cess (PA 3300). 

If a cycle or thread is the bottleneck, then the respective re- 
source management and data communication links are examined to determine 
the major bottleneck within the thread or cycle. Penalty coefficient 
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adjustments are made to the processor utilization equation. An alter- 
nate partition is sought that satisfies the end-to-end time requirement 
of the given cycle or thread under these more stringent constraints. 

If a component is above its allotted utilization, a check as to 
processor or memory balance bottleneck is made. If it is a processor, 
the processor heuristic is used to offload the offending processor. If 
it is a memory problem, an attempt is made to find a faster access memory 
or add a duplicate block if shared memory access is the bottleneck. 

As the processing of bottlenecks is performed, the augmented 
heuristic driver invokes PASS2 partitioning modules interspersed with 
additional checks for maintaining the appropriate thread and/or cycle 
constraints. If a new partition is found to be acceptable, it is saved 
for feedback to the performance simulation and further manual analysis. 
If not, the problems are identified for user evaluation. Appendix D 
contains the detailed design flows necessary to fully enumerate the 
algorithm. Additional changes are anticipated as the details of the 
performance simulator design are enumerated under Contract No. F33615- 
79-C-0003. 

3.2.4 Solution Summary Reports (PASS4) 

The report generation features of PASS4 are designed to provide 
printed summaries of a partition found by either PASS2 or PASS3 for a 
given candidate configuration. The specific formats chosen present the 
partition solution from five complementary, but different, aspects, 
including (a) partitioning priority level measurements, (b) task alloca- 
tions, (c) data block allocations, (d) processor allocations, (e) memory 
allocations . 

Figure 10 reflects a modular design flow based on user requests 
for any of the reports for a given partition j of candidate configuration 
i. This particular report generation capability should be implemented 
for access from batch job control, special user codes, as well as inter- 
active displays to obtain maximum evaluation flexibility to automati- 
cally recall and/or print alternative partition solutions for a given 
candidate. 

Specific output report formats are presented in Appendix B. The 
design demonstration. Appendix C, has sample output reports for user 
reference. 

3.3 FEASIBILITY DEMONSTRATION 

In deriving a meaningful* yet simple, sample problem, specific 
preliminary design material was obtained from Williams AFB with regard 
to an ongoing expanded design for the Advanced Simulation for Pilot 
Training multiple processor visual computational support subsystem. The 
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preliminary design material provided a realistic source of the format 
for ongoing trainer computational design input. It also included a mix of 
general-purpose and special-purpose processors. The information in this 
memorandum provided a good base for generating a sample problem; how- 
ever, the resulting sample problem required simplification of the con- 
figuration described to permit a flexible, yet easy-to-follow, manual 
demonstration problem to be obtained. 

The design factors in the original problem were very restrictive 
as to Central Processing Unit (CPU) task assignments and thus left very 
little room for alternative partitioning. This reinforces the fact 
that, in software design, tasks tend to be defined in terras of the 
selected hardware configuration features to meet computational needs, as 
opposed to specifying application computations and then matching tasks 
to the hardware selection. For the partitioning algorithm to be applica- 
ble to alternative allocations and partitions, the major feasibility 
issue concerns design language and means for inputting the problem 
definition from which the partitioning model is to operate. These issues 
are discussed in Section 4. 

For demonstration purposes, overview inputs, restrictive inputs, 
and detailed inputs have been incorporated to illustrate various aspects 
and paths of the partitioning process and to point out the tradeoffs in 
utilization of detailed inputs versus general estimates. The complete 
algorithm feasibility demonstration is inc^ied as Appendix C to this 
report. The basic order is the sample problem definition, user input 
sheets, user input echo summary, basic partitioning priority calcula- 
tions, sample performance feedback contingencies, and solution summary 
outputs . 

Figures 11 through 13 illustrate the major partitioning compon- 
ents as extracted and simplified from a set of Williams AFB ASPT prelimi- 
nary design notes for the visual subsystem. The overall processor con- 
figuration is denoted in Figure 11. The memory and external communica- 
tions are illustrated in Figure 12 to include both private and shared 
memory devices. It also includes processor-to-processor direct data 
transfer. Figure 13 denotes the simplified task flow used for demon- 
strating the input and output steps of the algorithm. The tasks of 
Figure 13 may be further divided into more detailed tasks for demonstrat- 
ing and testing specific features of the partitioning algorithm, once an 
automated version of the algorithm is implemented. 

The sample demonstration (delineated in Appendix C) permits the 
definition of potential automated implementation processes for handling 
real-world partitioning problems. The examples demonstrate the feasi- 
bility of an automated tool. Section 4 provides recommended implementa- 
tion steps for verifying and valid^r.ing the partitioning tool. These 
steps will require that the basic algorithm be automated to properly 
evaluate and demonstrate its performance characteristics for more rea- 
listic partitioning problems that tend to be of larger size than the 
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Figure 13. Application flow. 



manual demonstration examples. The manual examples will permit the 
basic logic to be verified for a controlled, small-scale application 
prior to "cranking out" large-scale partitioning problems. This will 
permit an initial level of confidence to be established in the automated 
version. 
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4. MODEL IMPLEMENTATION CONSIDERATIONS 



To successfully implement the software partitioning algorithm, 
an up-to-date technology data base for the flight training simulator 
computational devices is essential. This section delineates the data 
collection process and decision steps recommended for potential automa- 
tion and quality control of the algorithm defined in Section 3 . This 
section has been organized to go from an overview of the candidate design 
evaluation environment into a detailed evaluation support data base 
repository description, followed by computer selection criteria and the 
reconmended implementation schedule for automation of the software 
partitioning evaluation algorithm. 

4.1 FLIGHT TRAINING SIMULATOR EVALUATION ENVIRONMENT 

Typically, the development of flight training simulator candi- 
date designs for the Air Force are contracted out by the Simulation 
System Program Office (ASD-SD24). The computational subsystem design 
development is monitored and evaluated by the Deputy of Engineering 
Simulation (ASD-EN) . In some cases, the flight trainer development is 
directly contracted by a specific system office (such as in the case of 
the F-16 trainer). Currently, the contracted organization has the pri- 
mary responsibility for establishing both hardware and software require- 
ments of the computational system, subject to certain Air Force guide- 
lines and training capability objectives. The candidate design evolves 
through an iterative refinement of documentation and algorithm enumera- 
tion analysis, which typically progresses from system specification 
functional flows followed by the detailed enumeration of the candidate 
design* Each of these levels has narrative descriptions interspersed 
X7ith a variety of technical charts, drawings, tables, flow diagrams, 
interface definition:,, etc.; however, as denoted in B'igure 14, the 
volume of documentation for a training simulator quickly becomes 
unwieldy unless documentation traceability and content standards are 
adhered to and enforced via constructive reviews, which are geared to 
detecting and correcting errors early in the development phase. 

This effort has specifically addressed the software partitioning 
aspects of candidate design evaluation. The three major outputs of the 
partitioning algorithm are measures of the processing load balance, 
memory utilization, and estimated development implementation cost based 
on given timing and sizing input requirements of the respective tasks and 
data load for a given candidate configuration. For effective use of the 
software partitioning algorithm, the underlying mathematical model of 
Section 3.1 must be understood in terms of the processor utilization, 
memory utilization, and development cost formulations, which are the 
primary outputs. 
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date design evaluation, can quickly become unwieldy if content 
and traceability standards are not adhered to or enforced. 
The simulator computational subsystem interfaces with and 
coordinates a large number of the trainer simulator sub- 
systemii. 
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To obtain reliable outputs, a consistent, systematic procedure 
needs to be established with appropriate configuration management and 
quality assurance provisions and controls. The major implementation 
consideration for such a procedure is the establishment of a consistent 
data repository for pertinent flight trainer computational design data. 
No central repository for Air Force flight trainer computational designs 
currently exists, although various organizations (such as ASD-EN) do 
have their ovm evaluation data repositories. 

During the course of this contract, it was learned that the Naval 
Training Equipment Center (NTEC) in Orlando, Florida, does have a 
repository of all documentation associated with Navy training devices to 
include the computational subsystem, NTEC recently modified the 
required Data Item Descriptions related to the computational subsystem 
to be an integral part of training device development in conjunction with 
a proposed Appendix A to the trainer specification, MIL-STD-1644, 
entitled "Trainer Software Design, Control, Production Testing and 
Acceptance Procedures and Requirements," This proposed specification 
incorporates the top-down structured design approach with minimum stand- 
ards that are required of each milestone document and its associated 
review content, error detection/correction actions, and milestone com- 
pleteness determination. The procedures are in basic agreement with the 
development cycle presented in Section 2,1, This set of documents per- 
mits a consistent repository to be established and maintained for cur- 
rent-reference and analysis input for new development considerations. 
Unfortunately, it is still primarily a manual information storage and 
retrieval system when it comes to accessing data pertinent to software 
partitioning. 

The factors identified in Section 3,1 that influence optimal 
software allocation (such as: data block, task, processor, and memory 
descriptions) remain the same regardless of the system assumptions or 
presentation format. Indeed, these factors (Table 4) must typically be 
extracted from more than one document to obtain the complete set of input 
and constraint parameters defined in the mathematical statement of 
Section 3,1, To assist in the review of documents with respect to 
software partitioning of the computational subsystem, the supporting 
data base parameters have been segmented into five major areas with 
respect to flight trainer simulator: 

1, Trainer Computational Interface Requirements 

2* Baseline Application Components 

3, Candidate Hardware Configuration Components 

4, Technology Data Base 

5, Evaluation Criteria/Constraints and Partitioning Load, 

Figure 15 reflects the interactive nature of these data base areas with 
respect to technology capabilities and the development cycle up through 
the completion of the design but prior to actual implementation and test- 
ing. The upper area relates to milestone documents of the training 
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TABLE 4. DEVELOPMENT DOCUMENTS AND THEIR 
RELATIONSHIP TO THE PARTITIONING 
ALGORITHM FOR SOFTWARE SYSTEMS 



DOCUMENTf S) 


INPUT AREA 


Computational Subsystem 


External Device Interfaces 


Interface Specification 






Required Components 




Functional I/O Map 




Communication Rules 




^nd Prinri"l"ip<^ 

QlIU ri lUl ILICO 




Baseline Load(s) 


Software Design and 


Data Block Descriptions 


Data Base Specifications 






Task Descriptions 




Task Threads 




Baseline Load(s) Tasking 


Hardware Configuration 


Processors 


Design Specifications 






Memories 




Interfaces (Internal and 




External ) 




Communication Rules 
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SPECIFIC TRAINER DEVELOPMENT 
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Figure 15. Computational design evaluation must relate a specific design 
in terms of current technology capabilities for both external 
conmunications and internal computational subsystem details. 
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computational interface requirements, software design, and hardware 
design respectively. The lower half represents the technology data 
base, which permits an abbreviated means for entering the design details 
on which the partitioning algorithm is to operate. The left half relates 
the devices to be serviced by the computational subsystem, and the right 
half reflects the internal computational subsystem structure organiza- 
tion and devices. 

Although the data are extracted from independent sources, it re- 
quires interactive coordination and configuration controls to ensure 
that accurate, up-to-date, best estimates are utilized for the evalua- 
tion at hand. The evaluation criteria and constraint inputs facilitate 
configuration controls, parametric analysis, and partitioning flexi- 
bility with respect to prohibited and/or preassigned allocations in 
addition to initial allocations. The details of this segmented data base 
are now described in terms of implementation considerations. 



4.2 DATA BASE MANAGEMENT 

Two major recommendations are being made to facilitate orderly 
consolidation of the storage and retrieval for each of the five data base 
areas that provide the driving source of information for the partition- 
ing algorithm and candidate design evaluation process. These recom- 
mendations are as follows: 

1. The addition of a standard set of candidate design specifi- 
cation tables that address the software and hardware designs 
as independent sets of parametric measures. 

2. The establishment of a design evaluation data base reposi- 
tory utilising an interactive file management system under 
the configuration control of ASD/ENETC. 

This subsection supplies key factors that should be evaluated and modi- 
fied as necessary to facilitate an orderly transition to an automated 
algorithm implementation as presented in Section 4.4. Proper utiliza- 
tion will require a training indoctrination as to the potential benefits 
to both the flight trainer developer and evaluator communities. Before 
the recommended input forms are described, several master data struc- 
tures are delineated that have a direct influence on validity of data 
entries and provide the key to independent software and hardware design 
charac t e r iz a t ion . 

4.2.1 Master Data Structures 

These master structures include (a) data block characterization^ 
(b) memory characterization, (c) task characterization, and (d) proces- 
sor characterization. 
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Combinations of these structures are incorporated into the 
recommended forms for each of the five data base input areas presented in 
Appendix A. 

4.2.1.1 Data Block Characterization - Data characteristics such 
as source, volume, frequency, content, and destination are the real-time 
drivers of the computational subsystem from both external device and in- 
ternal task communications, command, and control. Table 5 denotes at- 
tributes required by the software partitioning algorithm for each data 
block that is acted upon or created by the computational subsystems being 
partitioned. Note that these attributes do not tie the data block to a 
specific storage device. Only external system blocks are identified as 
being related to a given type of peripheral interface; for example, a 
cockpit control setting input buffer blcrck has a definite source device 
that must be monitored at a predetermined sample rate. On the other 
hand, the data to be computed by one task and used by a sequentially 
dependent task are described in terms of minimum storage device require- 
ments for their storage and retrieval utilization. These master block 
definitions are then referenced by the block identification when refer- 
enced in the task descriptions (Section 4.2.1.2) or in evaluation allo- 
cation restrictions (Section 4.2.3). 

4.2.1.2 Memory Characterization - A wide variety of memories 
may be incorporated into a candidate design configuration for a flight 
trainer. For purposes of partitioning, memories are categorized (as de- 
noted in Table 6) to include read-only memory (ROM), writable control 
stores (WCS), main random access memory (RAM), rotating random access 
mem ory (RRAM), and sequential memories (SM). Within each of these 
categories are additional retrieval and storage characteristics for data 
representations of addressable units. These representations permit the 
generic data block parameters of Section 4.2.1.1 to be matched with 
appropriate memory devices in the candidate configuration for which 
partitioning is being performed. 

4.2.1.3 Task Characterization - Specification of task attri- 
butes, which are independent of the processing hardware, poses a very 
challenging problem area for incorporating the traditional hardware- 
dependent design customs and notations that have evolved not only in 
flight training simulator design but computational system designs in 
general. At this point in software design history, several emerging 
philosophies for design standards seem to be contradictory concerning 
the level of specification and the documentation language used to convey 
the detailed software algorithms to be implemented. At one extreme is 
the use of English-like structured pseudo code, which is favored for its 
features of being easy to follow and comprehend. On the other hand, 
there is an emphasis for precise, unambiguous mathematically enumerated 
representations that provide the specific computations but, if not 
annotated with English descriptions, they become very hard to follow, 
except for persons who are very familiar with the specifics of the 
algorithm. Most designs are generally a mixture of these two approaches. 



TABLE 5. DATA BLOCK CHARACTERIZATION 



ATTRIBUTE 


VALUES 


UNIT/MEANING 


Identif i er 


6-Character 


Provides a unique identifier 




MnPmnn i c 

1 II 1 CIIIV^I 1 1 v< 


fnr rrn ^ ^ -r pf PrPnrp and 






labeling purposes 


Level 


1 Character 






= 'S' 


System Interface 




= 'G' 


Global (used by more than 






one task) 




= 'L ' 


LUUQl UMC LQj^ UUw IIIUjL 






be saved 




= 'T' 


Temporary scratch area for 






a given task 


Discipline 


4-Character Code 


Provides basic I/O requirement 




for determining suitable 






memory device allocation 




= 'FIFO' 


Queue 




= 'LIFC 


Stack 




= 'SEQ' 


Sequenti al 




= 'RAN' 


Random 




" 'ROR' 


Ready-Only Random 




= "ROS' 


Ready-Only Sequential 




zt 'CBUF' 


Circrjlar Buffer 


Sizing 






f Maximum Records 


Positive Integer 


Records 


f Bits/Charac- 


Positive Integer 


Bits 


ter 






• Characters/Word 


Positive Integer 


Bytes 


f Average Words/ 


Positive Integer 


Words 


Record 






f Maximum Words/ 


Positive Integer 


Words 


Record 






0 Minimum Words/ 


Positive Integer 


Words 


Record 
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TABLE 6. MEMORY DEVICE CHARACTERIZATION 



ATTRIBUTE 


Mt\\ 1 ICC 

vALUEb 


1 IWT T /MPAMT Mf^ 


Identifier 


10-Character 
Mnemonic 


Provides a unique identification 
for each memory device in the 
technology data base for which 
the following attributes define 


Type 


4 Characters 






= 'ROM' 
= 'RAMM' 
= 'RRAM' 
= 'SM' 
= 'WCS' 


Read Only Memory 

Random Access Main Memory 

Rotating Random Access Memory 

Sequential Memory 

Writable Control Store 


Size in Bits 






f Minimum 
f Maximum 
f Increments 


Positive Integer 
Positive Integer 
Positive Integer 


Bits 
Bits 
Bits 


Number of 
Different 
Addressable Units 


Positive Integer 




For Each 
Addressable Unit 






f Level 


4-Character Code 






= 'BIT' 
= '6BB' 
= '888' 
= 'WORD' 


Bit Addressable 
6-Bit Byte Addressable 
8-Bit Byte Addressable 
Word Addressable 


f Bits/Unit 
Level 


Positive Integer 


Exclusive of Parity or Error 
Deletion Correction Bits 


f Read Access 
Time 


Real 


Nanoseconds 


f Read Cycle 
Time Unit 


Real 


Nanoseconds 


• Maximum 
Sequential 
Units Trans- 
ferred for 
Single Read 


Positive Integer 


Same as Unit Level 


• Write Access 
Time 


Real 


Nanoseconds 
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TABLE 5. MEMORY DEVICE CHARACTERIZATION (Sheet 2 of 2) 



AHRIBUTE 


VALUES 


UNIT/MEANING 


• Write Cycle 
Time/Unit 


Real 


Nanoseconds 


• Maximum 
Sequenti al 
Units for 
Single Wr i te 
Access 


Positive Integer 


Same as Unit Level 


• Frror Dptprtion/ 
Correction 


6-Charactpr Codp 

= 'PARITY' 
= 'SECDED' 


Parity Bit 

Single Bit Error Correction 
Double Bit Error Detection 


Number of Sup- 
pliers for Each 
Supp 1 i er 


Positive Integer 




• Identifier 


10 Characters 


Unique Identifier 


• MTBF 


Real 


Hours - Mean Time Between 
Fai lures 


• MHR 


Real 


Hours - Mean Time to Repair 


• MSPM 


Real 


Hours - Rescheduled Preventive 
Maintenance 


e MTPM 


Real 


Hours - Mean Time for Preven- 
tive Mai ntenance 
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which facilitates the overall functional flow, high-level presentation 
and permits a traceability structure for enumeration of detailed design 
computations and decision logic. 

The remaining problem area of design specification relates to 
the specific notation. Certain aspects of flight trainer computational 
algorithms have become well-defined, i.e., aircraft flight kinematics. 
These algorithms are generally used for making benchmarks on new candi- 
date processors. Thus, for well-established algorithms, a master set of 
simulation task benchmarks can be established for each candidate proces- 
sor being considered. New algorithms require a more fundamental bre^^k- 
out of the instruction mix to ascertain timing and sir.ing elements. In 
summary, a master set of software task attribute? are presented in 
Table 7. The establishment of a master instruction mix, task l/O 
descriptors, and task enablement features is recommended as one of the 
steps (Section 4.4) toward algorithm implementation. Related to this 
master instruction mix is the development language for task code genera- 
tion. Recent trends in simulator coding have incorporated FORTRAN code 
for the scientific mathematical application models, but there is still a 
strong dependence on the assembly level code for expressin/^ real-time 
executive and l/O handler modules to meet the real-time timing require- 
ments. The selection of a task design instruction mix notation should be 
coordinated with the simulation high-order language efforts and proces- 
sor instruction architectures. 

One way to obtain this information would be the use of a graphi- 
cal task flow representation, which included a standard design notation 
to indicate the instruction sequences, loops, and relationships with 
I/O. A flow notation, such as TBE's Input /Output Relationships and 
Timing Diagrams, can be automatically traversed with the instruction mix 
and I/O features being identified and reformatted for use with the parti- 
tioning algorithm^. This would require that a standard flight trainer 
computational design language and flow representations be established, 
thus providing a standardized way for documenting the detailed task 
computational designs. 

An important note is made here regarding the traditional means 
of expressing task sizing and timing in terms of adds, multiplies, 
branches, etc. The instruction mix need not be at the machine level. 
Instead, it should reflect a set of simulation macros, such as single 
variable linear table interpolation, and trigonometric functions. Each 
of these, in turn, is characterized for each candidate processor as to 
timing and sizing. If the simulation macro has been implemented in 
firmware or as part of a mathematical package, the sizing is reduced in 
terms of the main instruction storage for the task. 

4.2.1.4 Processor Characterization - Processor technology is 
constantly expanding in terms of operating system and instruction set 
capabilities. Table 8 lists processor attributes that pertain directly 
to the software partitioning , algorithm. The operating system features 
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TABLE 7. TASK CHARACTERIZATION 



ATTRlBUTt 


i/ni iicc 

vALUtS 


UNI 1 /MtAINING 


Identifier 


6-Character 
Mnemonic 


Provides a unique identifier 
for cross-reference and 
labeling purposes 


Source Language 


10-Character 
Code 


Must match entry in the 
master source language 
list maintained for current 
processor technology 


Instruction Mix 

for Each Instruction 

Type: 






• Instruction Iden- 
tifier 


10-Character 
Code 


Must match entry in master 
simulator instruction mix 
identifiers 


• Sizing Count 


Positive Integer 


Number of times this 'Instruc- 
tion appears in code 


a Execution Count 
Average 
Worst Case 


Positive Integer 
Positive Integer 


Number of instruction inter- 
actions considering looping 
conditions for average and 
worst-case logic 


Data Retrieval for 
Each Task Input 






§ Block Identifier 


6 Characters 


See Table 5 


• When 


6-Character Code 






= 'START* 


All records read at first 
of task before main proces- 
si ng 




= 'ALONG' 


Records processed one at 
• a time 


• Average Input 


Positive Integer 


Records 


• Minimum Input 


Non-Negative 
Integer 


Records 


• Maximum Input 


Positive Integer 


Records 
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TABLE 7. TASK CHARACTERIZATION (Sheet 2 o<' 2) 



HTTP TRIITF 


VALUES 


UNIT/MEANING 


Data Storage for Each 
Task Output: 






• Block Level 


1 Character 


See Table 5 


t Block Identifier 


6 Characters 


See Table 5 


9 When 


6-Character Code 






= 'ALONG' 


Records are output via indi- 
vidual processing 




= 'END' 


Records are output just prior 
to task exit 


f Average Output 


■iPositive Integer 


Records 


f Minimum Output 


Non-Negative 
Integer 


Records 


f Maximum Output 


Positive Integer 


Records 


FnAhl pmpnt 






• Type 


4-Character Code 






= 'TIME' 
= 'DATA' 
• = 'SLVD' 
= 'TAD' 


Time Enabled 

Data Enabled 

Slaved to Master Task 

Time and/or Data Enabled 


f Frequency 1 


Real 


Iterations/Second for Time 
Enablement 


• Frequency 2 


Real 


Iterations/Second for Data 
Enablement 


f Frequency 3 


Real 


Iteraticjns/Second for Slaved 
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TABLE 8. PROCESSOR CHARACTERIZATION 



ATTRIBUTE 


VALUES 


UNIT/MEANING 


Identifier 


10 Characters 


Unique identifier for pro- 
cessor with the following 
attributes 


Operating System 






• Multitasking 






▲ Levels 


Integer 
.GE.l 




A Number of 
Priority Levels 


Integer 
.GE.O 

.LE. Levels 


These many levels are ser- 
viced in a priority fash- 
ion. The remaining levels 
are serviced in a circular 
time-shared fashion. 


• Enablements s 


Integer 


Enablements/Second 


A Maximum Time 
Enablement 
Frequency 






A Resource 

Management per 
Time Enablement 


F10.9.GE.0 


Microseconds 


A Mdx^'rTu'm Data 
Enablement 
Frequency 


Integer 


Enablements/Second 


A Resource 
Management per 
Data Enablement 


F10.9.GE.0 


Microsecond 


A Maximum Slaved 
Enablement 
Frequency 


Integer 


Enablements/Second 


A Resource 

Management per 
Slaved Enable- 
ment 


F10.9.GE.0 


Microseconds 
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TABLE 8. PROCESSOR CHARACTERIZATION (Sheet 2 of 3) 



ATTRIBUTE 


VALUES 


UNIT/MEANING 


• For Each Task 
Level L 






A Maximum Number 
of Task Level L 


Integer ,GE.l 




ATask Service 
Scheme for 
Level L 


Code 

= .p. 
^ 'C 
= 'F' 


Priority 
Circular 

First-in, First Out 


• Level Resource 
Management 


F10.9 .GE.0 


Microseconds 


Simulation Instruction 
Set Measurements for 
Each Benchmark 
Instruction 1 






• Sizing 
Measurements 






A Number of Code 
Meniories 
Involved 






The Memory Type for 
Each Code Memory m 
(the first memory is 
the user task code — 
any other memories are 
predefined for this 
processor) 


4-Character Code 


Must agree with master 
memory types defined in 
Group 4 


A Length of Code 
in Memory m 


Integer ,GE,1 


Number of basic units used 
to describe memory m (see 
Group 4) 
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TABLE 8. PROCESSOR CHARACTERIZATION (Sheet 3 of 3) 



ATTRIBUTE 


VALUES 


UNIT/MEANING 


• Timing Measurements 
for Each Code 
Mamory m and k=l,2 




k=l Implies Average 

i\ c iMip i ICS nUibL UaSc 


A Number of Scratch 
Data Store Walts 


Integer .GE.0 




A Number of Scratch 
'Data Store Waits 


Integer .GE.0 




A Computational 
Total for All 
Memories 


Integer .GE.0 


Cycles 


• Application Develop- 
ment Measurements 
Using Language L of 
the Master Language 
List 






A One Item Develop- 
ment Charge 


Integer 


Man-hours 


A Change per Appli- 
cation Instruction 
of this Type 


Integer 


Man-hours 
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applicable to software partitioning relate to multitasking disciplines, 
limits, and resource management services. The instruction set is 
characterized in terms of the master simulation instruction set as 
described in Section 4.2.1.3, along with attributes for user memory I/O 
versus preprogrammed, resources plus development cost estimates. 

4.2.2 Suggested Input Forms 

The forms, as designed, may be used directly by a data keying 
operator to produce keypunched cards or entry directly onto a file via an 
interactive data entry terminal. Specific physical file formats are not 
specified since they will be a function of selected computer file image 
capabilities described in Section 4.3. Because of the volume of input 
sheets, they are presented in Appendix A for each of the data base files. 

During the design of the input forms, emphasis was placed on 
consolidation and cross-reference techniques that facilitate an organ- 
ized straightforward user input interface. The software partitioning 
algorithm requires an assortment of specific data to fully define 
trainer system interfaces plus computational hardware and software 
design details that must be accurate if a good partition allocation is to 
be obtained. The separation of forms is based on the five major input 
areas, and it is recommended that these areas be standardized for pre- 
senting the respective interface requirements, software task/data design 
relationships, candidate hardware design configuration, technology capa- 
bilities, and evaluation priorities, including the candidate initial 
design allocation as a starting point for partitioning optimization. 

4.3 TARGET COMPUTER AND SOURCE LANGUAGE SELECTION 

The selection of the computer system for the partitioning algo- 
rithm should consider, as a minimum, the following features , which must 
be incorporated to facilitate automatic implementation of the partition- 
ing algorithm and its potential expansions: 

1. Data base management system 

2. Structured program language 

3. Modified linear mixed integer program optimizer 

4. Computational speed and accuracy. 

-^h of these features is described in more detail in the follow- 
ing para^ aphs • 

4.3.1 Data Base Management System 

The interrelated, yet separate, data files (described earlier in 
this section) of the recommended flight trainer automated repository are 
best implemented under a standard data base manag/.ment system that 
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permits creation, update maintenance, and configuration management of 
all data and program files. It is recommended that system data file 
management utilities be available to the user in several different 
modes, including batch job control, interactive terminal commands, and 
user program code directives to permit a flexible, yet controlled, data 
access environment. Direct record access capability is an essential 
feature for implementation of the software task and block description 
plus the technology data base files. 

The amount of data is a function of the flight training simulator 
computational candidate designs to be evaluated. Table 9 provides an 
abbreviated summary of sizing relationships for each record type group 
contained in the respective files required for the partitioning algo- 
rithm. The data base management should include memory management of code 
and data required for execution. Internal tables utilized by the algo- 
rithm are sized in Table 10. The algoiithm code is estimated to be 
10,000 lines of structured FORTRAN exclusive of potential data manager 
and optimizer extensions. 

4.3.2 Structured Program Language 

Evaluation code (code used to facilitate manual analysis) is a 
very useful tool if it can be maintained under configuration control and 
permit expansion to more detailed models when necessary for a given 
evaluation analysis. Structured source code facilitates modularity and, 
thus, permits model expansion. Several source languages are included 
here as candidates for the partitioning algorithm implementation, 
including FORTRAN 77, JOVIAL, and ADA. These languages were selected 
based on current DOD-approved languages and language development activi- 
ties. Pros and cons for each are now presented. 

The widespread recognition of FORTRAN for scientific and mathe- 
matical programming makes it the preferred language of the three lan- 
guages considered. The newest ANSI FORTRAN 77 standards incorporate 
character manipulation, which is independent of machine architecture. 
Its use of structured logic includes both true and false process defini- 
tions without the use of extraneous *'iQO TD's." File manipulation capa- 
bilities have also been expanded to include file status checks and 
standardization of certain types of data storage/retrieval mechanisms 
that have previously required vendor-peculiar FORTRAN extensions« Some 
problems may be encountared with new compilers being released to meet the 
new TORTRAN standards, but these compilers should evolve rather quickly 
to support most of the ANSI 77 features. This will result in code that 
is more easily transported from one machine to another. This is an 
important aspect, since the partitioning algorithm does not require a 
dedicated computer system, and as such, it is envisioned as being a 
useful tool for flight training simulator developers and maintenance 
reconfiguration analysts, as well as for Air Force evaluators > Each of 
these specialists generally has his own in-house computer system 
tailored for specific analysis needs. 
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TABLE 9. EXTERNAL FILE SIZING REQUIREMENTS 



FILE 


RECORD 


lOPT 


TITLE 


TYPE 


GROUP 


TITLE 


SIZE 


1 


Trainer Computational 
Interface Requirements 


Seqrientlal 
80- Column 
Card or 
Keyboard 


I 


File ID 


20 Characters 




2 


System Interface Device 


1 to 3 Cards 
per Device 








3 


System Data Block 
(or Buffer) 


1 Card per 
Block 


2 


Baseline Application 
Components 


Sequential 
80-Colunn 


1 


Software Jc . ID 


20 Characters 




Card or 

Keyboard 

Entries 


2 


Data Block Definitions 


1 Card per 
'Block 








3 


Task Definition 


1 Header Card 

1 Card per 
Instruction 
Mix Definition 

1 Card per Task 
Block Reference 








4 


Baseline Load Definition 


1 Load Header 
Card per Load 

1 Card/Task/Load 




TABLE 9. EXTERNAL FILE SIZING REQUIREMENTS (Sheet 2 of 3) 



FILE 


RECORD 


lOPT 


TIRE 


TYPE 


GROUP 


TITLE 


SIZE 


3 


User Evaluator Inputs 


Sequential 
80-Column 


1 


Run File Identifiers 


2 Cards 






Card or 
Entries 


2 


Global Evaluation 
Factors 


3 Cards 








3 


Specific Evaluation 
Factors 


1 Card/Factor 








4 


Partitioning Assignment 
Constraints 


1 Card/Constraint 








5 


Selective Coefficients 


Coefficient 
Selection 


4 


Candidate Configuration 
Definition 


Sequential 
80-Column 


1 


File Identifiers 


1 Card 




Card or 
Keyboard 
Entr ies 


2 


Candidate Device 
Def i nition 


1 to 3 Cards 
per Device 


5 


Tech "^0 logy Data Base 


Random 
Access 


1 


File Identifer 


20 Characters 


1 




Hierarch- 
ical 
File 
Data 
Base 

Structure 


2 


Ma:ste" Technology Lists 

• Component Categories 

• Devices/Component 


10 Char/Catefiory 
10 Char /Device 



TABLE 9. EXTERNAL FILE SIZING REQUIREMENTS (Sheet 3 of 3) 



FILE 


RECORD 


lOPT 


TITLE 


TYPE 


GROUP 


TITLE 


SIZE 


5 


Technology Data Base 
(Concluded) 






• Instructions 

• Block Disciplines 

• Block Types 
9 Languages 


10 Char/Instr 
4 Char/Disp 
1 Char/Type 
10 Char/Lang 








n+2 


Component n's Specific 
Device Definitions and 
Attributes 


See IOPT-5 
GRP n+2 
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TABLE 10. INTERNAL ALGORITHM TABLE SIZING REQUIREMENTS 



TABLE 
IPT NO. 


TABLt TITLE 


WORDS 
(60-bit words) 


1 


Limits, Constants, and Code 


20 


2 


Current Problem Sizing Controls 


9 


3 


Priority Controls 


28 


4 


Current Processor List 


P*(13+i) 


5 


Current Memory List 


11*M 


6 


Current Communication Link List 


(3+3*QND)*9 


7 


Current External Device List 


(4+DB)*d 


8 


Task/Processor Allocation and 
Restrictions 


9*7* p 


9 


Memory/Processor Comfnunications 
Allocation and Restrictions 


(4+4e)*M*P 


10 


Memory/Block Allocation and 
Restricti ons 


5*M*B 


11 


Master Block List 


(11+M+2T)*B 


12 


Master Task List 


(16+5i+6*B+e)*T 


13 


Scratch and Local Parameters 


To be Defined 
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JOVIAL is mentioned because of its recognition by the Air Force 
as a standard language for embedded computer systems development. A 
major drawback is its limited l/O capabilities, which is a major factor 
with regard to the partitioning algorithm's large data base handling 
requirements • 

ADA is al80 mentioned since it is the DOD language being 
developed with source language standardization as a major goal to sup- 
port software development of new military computational subsystems. The 
on-going compiler developments are limited to experimental compilers and 
compiler design efforts. Therefore, at this time it is not a feasible 
candidate for actual algorithm development and testing. It will be 2 to 
3 years before it is available in an operational development setting. 
Further implementation/expansion should monitor and consider ADA since 
its features will permit more configuration control as well as the struc- 
tured expression of concurrent process control flows, l/O, and computa- 
tions with concise data base definition. 

In conclusion, FORTRAN is the recommended language for imple- 
mentation of the partitioning algorithm. 

4.3.3 > ^Mo'dified Linear Mixed Integer Prog ram Optimizer 

The partitioning algorithm has the potential for future inter- 
faces with a modified linear program mixed integer program optimizer. 
The current algorithm design is based on a heuristic algorithm driver 
that assumes that an initial feasible partition exists with respect to 
the basic rerl-time processing requirements of data availability, task 
timing, and less than 100% processor/memory allocation. From this 
initial feasible solution, it seeks to determine and isake improvements 
on the initial partition with respect to three goals: (a) processor load 
balance within given growth allotments, (b) memory utilization within 
growth tolerances, and (c) minimization of development costs. Although 
heuristics do not guarantee an optimal solution, it is anticipated that 
the complexity of priorities and data constants will change frequently, 
which makes the finding of the true optimal a meaningless exercise. 
However, optimizers can be employed to help find an initial feasible 
solution and to find optimal subset solutions under the control of the 
heuristic decision «:ree. In the case of the partitioning algorithm, the 
initial feasible solution poses the largest problem in terms of sizing 
and numeric accuracy techniques that are required. Table 1 summarizes 
the optimizer sizing as a function of the size of candidate designs to be 
evaluated. 

4.3.4 Computational Speed and Accuracy 

Although the partitioning algorithm is not as demanding as real- 
time sitaulation or control codes, it is important that it be able to 
support quick-turnaround evaluation runs to expedite the given evalua- 
tion c^ise. The complexities of the processor utilization calculations 



in terms of task computations, resource managemiint , and I/O are iterated 
with respect to potential processor tradeoffs for load balance: calcula- 
tions that involve a variety of attributes. Since the basic computations 
are subject to mathematical model expansions and changes, floating point 
capabilities are recommended to permit new equations to be introduced , 
as required, without the burden of fixed-point scaling. 

Units have been selected to keep related variable numeric order 
of magnitudes within computational limits of most scientific machines. 
These units should be periodically examined as technology advancements 
are made. For example, many current real-time flight trainer applica- 
tion cycles are based on 1-sec intervals with subcycles or subframes 
measured in terras of milliseconds. As timing improvements are made, 
these may take on smaller increments of time for application cycling , 
hence the need for their periodic reappraisal. Another factor is machine 
cycle time, which is currently measured in nanoseconds; thus, certain 
calculatio*>*5 involving memory I/O must be accumulated separately to 
obtain totals that can then be used to determine any appreciable I/O 
timing for tasks that handle large volumes of data in addition to compu- 
tational processing. Typically, 32-bit floating point can represent six 
significant digits. Thus, if a basic unit is assumed to be 1 sec, the 
nanosecond effectively is disregarded unless accumulated separately. 
However, if either double precision (64 bit) or 60-bit single precision 
is used, there is no problem. An alternative is for task memory I/O, 
resource management, and individual instruction timing computations to 
be accumulated for total task time in microseconds, and then task times 
may be added separately for a given application cycle time in terms of 
current task/cycle relationships. Thus, there is the need for floating 
point, with a minimum of 32-bit words sufficing for most operations, and 
either segmented units or double precision variables to account for 
application subtask timing computations. 

The use of preemptive priorities rather than weighted priorities 
permits processor loading, memory allocation, and development costs to 
remain in their standard units without any input scaling and output 
reselling. However, in each priority level, numbers for a given task or 
data block should be summed separately from totals being used for total 
memory or total processor utilization to avoid underflow • accumulation 
problems . 

4.4 RECOMMENDED IMPL E MENTATION SCHEDULE 

The major tasks and their hierarchical relationships are 
depicted in Figure 16. Each of these tasks is briefly described in this 
section with cross-references to appropriate report sections for related 
details. Although some parallel cask sequences are depicted, there are 
some interdependencies , as denoted in Figure 16. These interdepend- 
encies are basically handled at major detailed reviews, which are recom- 
mended to be held quarterly to assess the implementation progress, to 
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tasks. 



ensure that interface definitions are adhered to, and to establish more 
detailed interfaces as the appropriate operational consideration details 
become knovm. 

Figure 17 groups the tasks into four major implementation phases 
over a 2.5-year period. There is an overlap between Phase III and Phase 
IV, with the major emphasis of Phase III placed on basic (as currently 
designed) algorithm validation and with Phase IV emphasis on an expanded 
validated model incorporating an optimizer for selected aspects of the 
partitioning algorithm. The implementation tasks are now described by 
phase. To make a complete task statement, there is some redundancy with 
earlier report sections. Cross-references are made to avoid excessive 
redundancy. 

4.4.1 Model Validation Plan and Selected Computer Interfaces 

Although the candidate computer selection aspects have been de- 
scribed (Section 4.3), the specific computer implementation must be fur- 
ther delineated to obtain a practical partitioning allocation and eval- 
uation tool for flight trainer simulator computational candidate design. 
Existing evaluation computer facilities should be reviewed for current 
formats and data collection procedures in addition to the current com- 
po,ter capabilities to contribute basic inputs to the Phase I tasks, which 
are now briefly described. 

4.4.1.1 Validation Flan - The sample problems manually demon- 
strated under this contract have verified the feasibility of the parti- 
tioning algorithm design. However, they do not constitute a model cali- 
bt^ation case from which a confidence level of model validity may be 
derived. As evidenced in the mathematical statement of the partitioning 
j^i'oblem (Section 3.1) , there are many interrelated variables and factors 
that drive the partitioning process, necessitating some parametric auto- 
mation techniques to fully analyze the automated design validity and 
stability for real-world data. The validation plan will permit con- 
trolled algorithm implementation testing to determine its validity with 
respect to known partitioning situations of selected flight training 
simulator compu?ratational designs. By addressing evaluation partition- 
ing problems to be handled prior to algorithm coding, the evaluation 
community is essentially establishing the foundation for the algorithm 
acceptance test with respect to its role as an evaluation tool. 

As a minimum, the validation plan should identify the flight 
trainer system(8) to be used as the algorithm implementation baseline. 
It should also extrapolate intended sizing of the algorithm application 
in texTiis of the number of each data base item described in Section 4.2 
(i.e., number of tasks, blocks, processors, memories, etc.). A set of 
test cases should be draftrd in an outline format as to specific algo- 
rithm features to be incorporatad and tested for both the basic model and 
the expanded model. 
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4.4.1.2 Data Base Interface - The specific flight trainer com- 
putational design repository format and data base management utilities 
should be delineated by this task. This includes finalization of the 
user interface formats (such as those contained in Appendix A) and the 
format by which the partitioning algorithm may retrieve its inputs and 
store its outputs with respect to the repository and the interacts 
and/or batch user. 

This task incorporates the data collection, storage, and 
retrieval mechanisms, plus quality assurance steps necessary for algo- 
rithm implementation and usage. The repository data management should 
incorporate responsible agencies for each input area and make maximum 
use of pre'-editing and file management utilities of the selected com- 
puter system. The results of this task should be compiled in the form of 
a users' manual for the flight trainer design repository and specifi- 
cally address the partitioning algorithm interfaces. These interfaces 
include the master design simulation language instruction set and guide- 
lines for processor, memory, fa^^k.^ and data baseline descriptions 
(covered in Section 4.2) that will streamline the orderly prep^aration of 
inputs and permit gradual contLolled growth into a fully tested and 
implemented repository system for multiple evaluations. 

4.4.1.3 Computer Selection - Computer candidate selection has 
been discussed in Section 4.3. This task ties Phase I activitieti 
together to determine the specific coding standards and i >terfaces to be 
employed for algorithm implementation for a given computer facility. 

4.4.1.4 Optimizer Interface - This task permits the long-range 
interface goals to be defined for potential optimization steps in the 
heuristically driven partitioning algorithm. This is a major area for 
further study and, as such, is recognized in Section 5.3. 

4.4.2 Automated Algorithm Verification and User Design 
Foundation 

Phase II permits the initial automation of the basic algorithm 
and delineates addition.! programs that will aid in the bookkeeping and* 
increase compataticrual confidence levels of an expanded partitioning 
algorithm. Each of the tasks is now defined. 

4.4.2.1 Establish Model Validation Procedures - This task 
expands and enumerates the test cases outlined in the test plan of Phase 
I. The nature of the basic partitioning algorithm is to seek and, if 
possible^'f ind an improved partition of tasks. Thus, the test procedures 
r..ast include the means for reconfiguring, the subject flight trainer for 
which ^sf-'^/^upposedly "beCiter" partiiiion has been found. In addition, 
related performance measurements of the newly partitioned configuration 
must be lipe-iified as to t;hat an^ how they are to be collected and 
evaluated to access the pr^dici. J partition improvements of the parti- 
tioning algorithm. To ese^xr- id this step, the multiple processor 
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simulator being designed under separate contract may be used to provide a 
quick look at the dynamic aspects of the new partition prior to making a 
reconfiguration decision. All of these considerations must be placed 
into a timeline for algorithm validation testing to account for perrais-- 
sible reconfiguration in the partitioning restriction. For example, if 
special -purpose tasks may only reside on special -purpose processors , 
they shoul . be declared as such in the partitioning algorithm evaluation 
options. Thus, realistic, measurable validation test procedures are the 
goal of this task. 

4.4.2.2 Design Repository Programs - The users' manual of Phase 
I will undoubtedly require specific repository storage /retrieval pro- 
grams to be designed to augment the sysuem-supplied data base capabili- 
ties to support the flight trainer eyaluators "input jargon" and to 
efficiently handle the input and subsequent updates to each of the vari- 
ous files to ensure consistency and completeness of any given repository 
transaction. The results of this task constitu^o the detailed design of 
each and all repository programs to be implemented in Phase III. 

4.4.2.3 Code /Verify Basic Algorithm - This task is the most 
straightforward of all of the tasks and simply entails the coding, debug- 
ging, and verifying of the basic algorithm as designed and demor.strated 
as part of this subject contract. This provides the working baseline for 
all future expansion in both model repository and optimizer interfaces. 
The results of this task provide a source code listing, verification test 
case execution outputs, and documented interpretation. 

4.4.2.4 Design Optimizer Programs - The emphasis of this task is 
to be ploCf'^'i on upgrading and complementing an existing mathematical 
optimizer package selected in Phase I with resp^^.t to computational and 
logic needs peculiar to the partitioning plication. This task 
requires extensive knowledge and experience with mathematical optimiza- 
tion codes and t'reir numerical stability in terms of accuracy, scaling, 
iteration^ J. masking techniques that can judiciously expedite the 
solution S)jj--~'^: search for initial feasible solutions. The task also 
requires kn-:r.'edge and experience with optimal subproblem solutions as 
called by tiie heuristic driver of the basic algorithm. The results of 
this task will comprise the detailed design of programs to be implemented 
to support the optimizer interface. 

4.4.3 Basic Model Va l idation and Expanded Program Interface 
Development 

This critical phase permits the large-scale, reril-world data 
assessment of the basic algori*-ltm to be made. The first part of Phase 
III is associated with specific g ta collection, scripting, .^nd support 
program coding. The latter part of this phase incorporates efforts of 
the first part for baric algorithm validation testing. In addition, the 
optimizer programs are developed in preparation for the Phase IV 
expanded model. Each of the Phase III tasks is now described. 




4.4.3.1 Script Validation Data - Validation input data must be 
collected and prepared utilizing the validation input procedures for 
each test case for basic algorithm and expanded algorithm validation 
cases. A ti -t case can not proceed until its basic inputs have been 
properly prepared . 

4.4.3.2 Develop Repository Prog r ams - The programs designed in 
task 2.2 of Phase II are coded, debugged, and verified by means of 
validation input procedures to assist in the input processing of 
task 3.1. 

4.4.3.3 Develop Optimizer Programs - This task codes and debugs 
the programs designed in task 2.4 of Phase II in preparation for expanded 
algorithm verification and validation of Phase IV. 

4.4.3.4 Validate Basic Algorithm - Each validation test case is 
made in the order prescribed in tha test procedures. If any problems are 
encountered, their impact on the test plan and case procedures must be 
fully evaluated to determine what action, if any, is nec^=^-H,.sary to con- 
tinue the test program. All test execution reports sbculd b^- included as 
appendices to the test summary report. It is anticipated :.hat certain 
validation tests can be run prior to complete implementation of the 
repository to exercise the fundamental paths of the algorithm. 

4.4.4 Expanded Model Verification, Validation, and Formal 
Acceptance Testing 

Phase IV paves the final path to the realization of the parti- 
tioning algorithm as part of the standard flight rrainer simulator comp- 
utational design evaluation and/or design guide tool. The full reposi- 
tory and added optimizer capabilities developed in the first three 
phases are now integrated and tested to provide a controlled user inter- 
face for multiple eval^iation situations. The tasks are now defined. 

i!/.4.4.1 Verify Expanded Model - This task consists of selected 
basic algorithm test cases to verify that these cases are still properly 
handled in the expanded model. In addition, new path verification tests 
are incorporated by the designer to verify that new capabilities are 
working as designed • 

4.4.4-2 Validate Expanded Model - This task performs the exten- 
sive testing as defined in the validation procedures for the extended 
model. As with basic algorithm validation, if any problems are 
encountered^ their impact on the test program must be evaluated and it 
must be determined whethei- any action is necessary for continuance of the 
test program. All execution results should be included as appendices to 
the test summary documentation. 

4.4.4.3 Fo nnal Acceptance i'est - The complexity of the parti- 
tioning algorithm and its potential evaluation decision--making impact 
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necessitates the need for formal Government acceptance tests. These 
tests should be scripted and performed by an independent organization to 
fully assess the delivered capability with respect to completeness of 
documentation, configuration, quality, and purpose. The major developer 
is involved as a consultant to explain or expard documents and to respond 
to any questions concerning the delivered operational package. It is 
anticipated that Government flight trainer system evaluators will be 
responsible for scripting and conducting these independent test proce- 
dures since the test will serve as a training task that emphasizes the 
intended operational user environment of the algorithm. 

4.4.4.4 Final Report - The emphasis of this task is to be placed 
on finalizing documentation of the automated algorithm capabilities, 
findings , and conclusions . This documentation should be accompanied 
with the final user, test, and program maintenance documentation for 
specific program implementation details. 




5. CONCLUDING RE-A/IARKS 



Soft'^are partitioning is a complex, design development/ 
evaluation, decision-making process with many tradeoffs to be analyzed 
for selecting a good candidate flight training simulator computational 
design for a particular operational trainer implementation or upgrade. 
This section briefly summarizes the details presented in Sections 2 
through 4 in terms of the study findings, related v/ork, and areas for 
further study. 



5.1 FINDINGS 



Candidate software designs expressed independently of candidate 
hardware are the basic key design feature that permits software parti- 
tioning flexibility. This is not the traditional design approach cur- 
rently in use for system design. This project has defined the types of 
design data that will permit independent assessment of baseline software 
tasks for alternative multiple-processor configurations. The key data 
areas are the establishment of a standard design language and an auto- 
mated repository for the given application design data. 

The partitioning algorithm has been designed as a general parti- 
tioning algorithm for software systems, and it is the data collection 
process (Section 4,2) that will make this algorithm unique for a given 
application implementation. In this way, it is seen as a useful tool for 
the evaluation of a wide variety of computational subsystem designs 
since it is not constrained to current configuration, technology, or 
application, 

5,2 RELATED WORK 



EKLC 



The results of this effort are closely coordinated with Contract 
No, F33615-79-C-0003 for the AFHRL Advanced Multiple Processor Configu- 
ration Study, The multiple-processor study is concerned with features 
and techniques for assessing the predicted performance of given altern;^- 
tive candidate designs. The partitioning algorithm is looking at task/ 
d&ta allocation from a static analysis point of view to ensure that real- 
time computational requirements are met with a balanced load. The number 
of entities that must be considered requires that parametric analysis in 
terms of average or worst-case numbers be used in the partitioning 
process. The dynamic environment of the flight trainer computational 
task allocation requires the addition of network, queuing, and simula- 
tion (batch mode) tools to predict and assess the performance of a given 
allocation partition with respect to representative scenario loads and 
resource management rules. The multiple-processor configuration con- 
triict is incorporating and expanding the conceptual repository to 
include the dynamic performance design aspects that are pertinent to 
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alternative computational candidate deoign evaluations for operational 
flight train'^rs. *rhe results of this related effort are to be published 
in the final report scheduled to b?5 <listributr3d on or abouc 31 Oct 80. 

5.3 AREAS FOR FURTHER STUDY 

Advancements in systems development and training features are 
sources of continuous change for flight trainer systems. A "good" system 
today may be obsolete in years or less if it does not possess modular 
design capabilities. ^ .s is particularly true of the computational 
system, which must act ^8 a coordinator, interface, and decision-maker 
to assist the hu^ian operators and commanders to better perform their 
jobs . As new/upgraded f iight trainer systems are required, the basic 
design models plus new/modified modules may very likely require reallo- 
cation of new processor, communication, and memory technologies . Two 
major areas of study have been isolated as the key to potential reali- 
zation of a truly automated software partitioning algorithm: 

1. The employment and expansion of mathematical, mixed integer, 
program optimizer techniques for large- ."r.ale partitioning 
with multiple objectives 

2. The development of a master flight training simulator compu- 
tational subsystem design repository. 

These two areas have been incorporated as major tasks associated with 
automation of the partitioning algorithm described in Section 4.4. 

In conclusion, automated software partitioning is feasible. It 
will require further study, design, and test stepr> that are directly re- 
lated to computer facility selection f'^r its implementation. The major 
training simulator candidate design impact would be toward standardiza- 
tion and separation of the software design representation and data from 
processor hardware configuration representations and data. The results 
of the standardization would permit a consistent flight trainer computa- 
tional design automated repository to be established and used in both new 
design and current design evaluation tradeoffs in the areas of software 
partitioning and predicted performance of multiple-procassor configu- 
rations. The use of an optimizer will permit certain tradeoffs to be 
automatically made and determined in c more straightforward manner, per- 
mitting more time for manual evaluation comparisons and decisions. 
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SUPPORT LIBRARY Mf.MQRY 1 i i , , t i , i i I 


K 


M 






BY Trs 


WOPDS 






J. L 


1 . 


i 1 


. 1 i 1 




, t 1 . 1 t i 


MULTI TASKtNG FEATURES AND MESOURCFS 
















I EVEI. 


MAX 
TASKS 


SFHVICED 




RESIDENT (R) 








ENABLEMENT IIF 


" iUMCE MANAC;' 


fVT 


K -■ 
C - 

F - 


KRIUMI 1 T 

cincDLAn 

FIFO 




NGN RESinENT {NRJ 
BATCH (B) 


CIRCLE TYPE(S) 
TIME SLAVE DATA 




1 Hi- • 
TJr.' 


imcY 

SECf^ND 


i HIIEAH/ 
^AOLEMEMT 


1 . 1 1 1 1 l-t . 1 t . 1 1 


t 1 . 1 1 I * . . . 1 




u 






R 


NR 


R 


T 


S 




D 


( > 1 1 . . I 1 1 


L-i 


. t . . . . 1 


1 1 I 1 . L J-l . 1 t 1 1 1 


1 i 1 1 i 1 1 . 1 • I 




u 






R 


NR 


n 


T 


S 




0 


1 \ Lj_ju.i— iJ 




. 1 . . . 1 1 


I 1 1 1 1 L l-f . « 1 1 1 1 


1 1 1 1 t i • 1 1 r j 




U 






R 


NR 


B 


T 


S 




'0 


1 1 i i . . 1 - J 




■ 1 1 1 1 1 l-l 1 1 1 1 1 1 


1 1 . . I i . . > ! 1 




U 






n 


NR 


B 


T 


S 




0 


(.11 11. 






1 4 1 1 . !_ I-I . . 1 1 t 1 


\ 1 1 . 1 t . 1 . 1 1 




U 






R 


NR 


n 


T 


S 




D 




1 1 




. 1 1 1 ;. J 


) 1 1 1 1 i-l I > 1 1 1 1 


I 1 1 1 1 { I 1 t 1 1 




U 






R 


NR 


B 


T 


S 




D 




1 1 




1 i 1 . . 1 : 


1 . 1 I 1 1 l-l . 1 I . 1 1 


i ... t i .... t 




U 






R 


NR 


B 


T 


s 




D 








1 * J 1 1 i l-l . . 1 I . 1 


1 . 1 1 1 i t 1 1 1 1 




U 






R 


NR 


R 


T 


s 




n 


1 < 1 1 t 1 < . ( 



































C7 r 



DASU; 

Mr ash: 








AVf 








w 








; ANGUAC 










t. t 1 > 
I 1 ■ 1 


1 J 
1 ) 






! ; 1 













ror 


. 1 ! 





USiNr; I ] 1 I I > . . 1 f-rnAilNo .SYStFM 



TIMING fCYCLESI 

FrTriics comi'l: ' ATif-'NAi. 


nr v!-'LorMCMr (manycams} 
mn;f riMr prn occun'^rx 


. - . 1 1 1 1 I 1 1 1 t M 1 1 1 . 1 1 If] 


' 1 I 1 I : 1 1 1 .... 1 , 


■ ■ L. . i 1 1 1 1 ( L_i_l 1 : f : 1.1 




t I 1 1 1 1 1 1 . t J 1 1 !> 1 1 1 1 1 1 


I I. 1 1 1 ! 1 1 f 1 , 1 , 1 1 t 1 « 1 1 


! 1 i 1 1 1 t I : ! 1 1 1 1 t 1 ) . 1 1 . 1 


« ' _ ill !..«. iJ [ l.X t lit I t 


1 1 1 1 1 I 1 I 1 1 1 1 1 t 1 1 1 


I ) 1 1 1 1 1 i 1 t 1 1 1 1 1 1 1 1 







J-J L.;_JL.J L 



.Lj_i.j_iJ 



HI 1?^ 



- i i I i t f \ 



_J_J 



MFMOnv DEVICE OF f INI I lor. 



AnDiiriSSABLP v^w: 



AM SM 



nf AD (rErcH) 



A' SS 

ir. ;r) shcj 



CYCLE 



—J L 
J L 



WAX 
UNITS 

mE At) 



Ljl. 



ac(:f.s<? 



. CI.C 



M/",H 

wnn~EN 



I 1 I I I ig. 







1 > ' ' « ' ' 
1 t < » t I ^ 



L-l_I^LJUJUL 

l,J_.!.X -l_JUl - I 

: 1 t 1 1 ■ J 



J 1 1 t t I 



' I ' « ' ' 



-1 1 I I <_ > 



1 » ■ ■ » 



-l_J t 1 1 1 f 



J Lju.j_jljl. 



-LX. 



I L t 1 1 



J— i-J I ' 1 . < _ 



TECHNOLOGY DATA BASE lOtNIIHER 1 t . t ■ I ■ . . . I i . . . I . . , i 1 

COMMUNICATION LINK DEVICES 



DEVICE 
IDkNIlFlEn 


BASIC IHANSFER UNIT 
MAX UNITS 

MAX RAlt (UNITS/SEC) 


INTERFACING DEVICE ATTRIOUTES 


TECH DEVICE 
TYPE lUtWrtFJEH 


TRANSMIT 
UN5T MATE 


RECEIVE 
UNIT RATE 


1 ... 1 1 .... 1 


1 1 i 1 1 


UU 1 1 1 1 1 1 1 1 1 1 1 





till] I . 1 . . 1 . . . , 1 


1 1 ^ 1 1 1 1 1 1 1 1 


1 1 t 1 1 1 1 « > 1 1 


UxJ 1 1 1 1 1 1 1 1 1 1 1 


1 1 . 1 J t t 1 1 1 1 . . I ., t 


1 1 1 I i I . . 1 . 1 . . . , 1 


I 1 1 1 1 1 J 1 1 1 1 


I . 1 ] 1 ... 1 .... 1 


1 1 1 ! 1 t t 1 . . 1 . . 1 1 1 


t 1 I 1 1 1 » 1 


1 1 1 . 1 


UU 1 1 1 1 1 1 1 1 1 1 i 


t _1 J '1 1 a . 1 ^ 1 J ^ 1 . 1 


1 » 1 I i I . 1 . . f . i . . I 


LjJ 1 1 1 > I t > I I 1 J 


1 1 1 I 1 1 1 1 L ( t t t . 1 




1 1 1 1 t I 1 1 r 1 t 


I L 1 1 1. J t 1 1 . 1 


UU liiiilti.it) 






1 1 i 1 1 1 t 1 t t i 


i . 1 1 . . . . t . . . 1 t 


I .1 ,1 , 1 t I 1 I 1 1 1 t 1 t 1 






UU I t 1 1 L 1 1 t 1-L.J 






UU 1 1 1 1 1 1 1 1 f_iJ 


lilt! 1 V i it 1 t 1 1 1 1 




1 1 1 1 1 1 i_iJ_i ) 


1 1 1 4 1 1 J 1 . 1 1 


UU 1 1 1 k 1 t 1 t t 1 1 


1 1 1 1 t 1 I . t t 1 1 1 1 1 




I 1 1 1 . 1 1 t t • 1 


UU 1 1 1 t 1 1 t 1 1 1 1 


1 1 1 1 ' 1 < 1 : 1 1 1 1 1 1 f 






UU i 1 1 1 1 i 1 1 1 1 ! 


III'' I 1 1 t 1 1 t i 1 1 1 




LjU 1 t i I I t ^ I I I 1 




1 1 1 1 1 1 1 f 1 1 ! ■ t .i.t^l 




L l_i 1 1 I L t > 1 1 


LjU 1 I i i I t 1 t ) I 1 


1 1 ^ 1 : t t i 1 1 1 1 1 1 1 1 


1 ... 1 1 .... f .... » 


t 1 1 . i 1 1 . . . 1 


1 • • 1 .... 1 




j 1 1 r t 1 t 1 . . 1 t 1 ■ i) 




I • 1 1 




1 1 1 1, t 1 t t 1 f i 1 1 1 1 1 









CANDIDATF. CONF inURA TlON IDEN riflEn i i i i i I i t i i I 





CANDID^ 
iDENIir 




rtt>- qfi 






! or I (ON 




TYPE 








I 1 1 1 • • < 1 




1 , , . . , , . » 




i-JL L^J 

1 


{ 1 1 • 1 1 1 1 '] t 




1 1 

U 

u 




L.I J 1 > 1 1 1 1 




I 1 . .1,1] 




I 1 








1 1 1 • . I ! r i 


i V i « ■ 1 1 1 1 1 J 




I J 1 1 ■ ' 1 t 1 J 




t .1 






I 1 1 1 i 1. I, 1 I J 


u 






1 1 { 1 1 1 • t i 1 .1 


t 1 1 J r 1 


I 1 1 i 1 1 1 1 1 1 


u 
u 
u 
u 
u 
u 




I 1 1 I 1 ! t 1 1 1 1 




III-. 1 1 1 1 




' 1 ' ' ' ' « * 1 




1 1 




till! ' I 1 1 i 






L 1 I L. i_ Li J 


^ 1 1 


I . , . , I . . . . 1 




L 1 . _i 1 1 ' 1 . 1 1 






I 1 1 1 t 1 ^ 1 1 1 1 


S 1 1 


1 .... 1 .... 1 


t 1 1 1 1 1 t < 1 1 1 


1 1 t 1 1 t > 1 1 I'll- if; ; 


111 . f 1 1 n 1 


L-U 


[ 1 1 1 I 1 1 ( 1 1 i 


1 1 1 1 1 1 1 1 1 1 1 


1 . , . . 1 , . . 1 


' '' -X-J 


1 1 J 


111 1 1 t 1 1 1 i 












ru 


rnocEsson 
DrviCF 




1 ACTIVE LEVEL" 
4 LANnUACJE 2 


SYSXfM 


3 • LAN(5UAGE 1 
(i LANGUAGE 4 


C0NT(NUC ir 

MORE LANr.UAnrS 
AMF STECiriFD 


MM 


M( Monv 

OF VICE 




1 . sr/rwo UNIT 


r r^y 








CL 


COM 






iNfcnrAciNG 




< - -IW * 


rninniTY 




CONTINUE ir 




DtvrcE 






DEVICF TYPE 


t-xw ■ ■ 








MOnC INTERFACING 










1 










OEvrcFS 
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BASE LINE son WAR!? A CATIDN lOrNIinCAir 'J l . ■ 



DATA niOCK DEFINITIONS 



c 



ID 


LFVEi 


■otscir NT 


1 s- ! 

{ |r . MAXlV'tiM 


MIN 


IMUM 


nrroni) n in 




DMS/ 

nvTE 


nvTiEs 

WORD 


MJNiMur. 


AV fn AOr MAXIMUM 


I 1 1 1 1 1 1 . 1 1 1 


u 

LJ 
U 

u 
u 
u 
u 


I ... 1 


1 1-1 1 I.J 


U_i_i . ljlJ 


1 i 1 


I i 1 


I / I I ,i.J[-j..u-i„jU 




1 . t . . 1 . . . , i 


... 1 


L. 1-! . 




{ 1 1 


1 1 1 


L_i-jL_i. I Xi..i_j-jlJ 


Lj_J_i,JLJ_l_J_ 1 1 1 . 1 . . . , i 

' 1 '. , 1 . , 1 . . . p r 


t ... 1 1 ... ! 


... 1 


L-i-J-1 r 1 , , . , ; 1 


1 i r 


l_l_J 


!'.^ 1- 1., i.J ,1 


Lu_j-a_jJLi_j_. ; , . . . 1 . . . . t 




-J 1 iJ 


L-L»-' ' ■ 1 


I u 
1 1 1 


l_l_J 

1_lJ 






I . i . i t . . . < } 


-J J 1 1 


L_i_J-| i = . . 1 


! , . 1 


1 

l_A-a_l-jJ^J till 


1 ' ' 1 » 1 r i_L . t 1 . I . . . , 1 
t . . , . 1 . . . ...» . 


t 1 1 1 1 t 1 1 1 1 1 


^.j 1 t_l 


L_i_J-l , . , 1 


L 1 1 


1 i 1 


1 i r 


[ I _l t 1 _1 4 . i ( 


I , . . . t . , . 


III II J 


t 1 1 . . 1 . . . . 1 


i 1 I 


L_i_J-l 1.1 , 1 




1 i 1 


I : I 




I . . . . 1 . . , } 


I 1 1 1 1 1 1 1 1 I.I 


^ > . . . i . t . . 1 


1 ij 


1 ' >-» . , 1 1 


1 1 1 


1 f. 1 


( : i .1.-1 l.j^l._.f 


1 . • i 1 1 . . . . 1 


I 1 1 1 1 1 1 1 1 1 1 
t , ... 1 .... 1 


1 i 1 . . 1 . . . . > 


u 
u 
u 
u 
u 
u 
u 


-.J 1 ij 


L_lJ-1 11.!;! 11, I ^ . 1 


1 1 1 


III 


!— L-.l_JL \ ,S f..,JL-l I, 1 


1 . t . . 1 . , . . 


I .... 1 .... 1 


1 ....(.... 1 


1 . . 1 


1 . I-I . . . ! . , 1 , , , . 1 


1 1 r 


1 1 r 


1 ? I . 1 , 1 1 1 1 . 1 




1 ' • ' ' 1 


1 1 1 1 1 1 . t . 1 1 


. J ii.J 


1 . l-t . . . . 1 . . . 




1 1 r 


\ i » 


1. -L L \ 1 . I ■r„JL^l_J.J 


( . > . . 1 . , 




1 .... 1 .... 1 


- J > ij 


l_l_J-l 1 , , , I , i 


1 . i ^ 1 i 1 1 


1 1 r 


1 1 r 


• Li_»^jLJ 

1. 1 .L,JUJ J 


C . . . . 1 . . . 


1 1 1 1 1 1 1 1 t 1 t 


t . 1 . . I . . . . J 


. J II.J 






1 1 r 


'» . , » , * 


I— J — 1 — > — » — 1 — t—i — I -n 1 1 { t 1 . . . . . 

L_i_i_i_i_l 1 . 1 , 1 ... 1 .... 1 


1 1 ( . . 1 . 1 1 . 1 


J I I.J 


Li-J-I 1 J 1 1 !.. ^_j_J 


1 . 1 1 . 1 r . f 


1 1 r 


1 1 r 


: 1 V.I n .i.j..rj 


Li. J 1 I I 1 1 1 1 1 1 t . i . . . . ) 


1 1 1 . . 1 . . . . 1 


1-1 1 1 1 




I 1 


1 1 r 


L_i_J 


Li__' O-jlJLji-. « ,j_i_J 


t-i 1 1 1 1 t 1 _t > . 1 . 1 . . . . 1 



ERIC 



-1.- — 1 -L J 
"> NO 



FMF'.M tVPE' L_L ' » f 



SIZING 
COLfNT 



SlAVcPt 



DATA 
BLOCK 



MAXIMUM TIME: L. 

rntOllENCV: U 



iHrui' si: 
UPDATE Al 

outrun Er« 



: I/O TEH EXECU'iO' 



rrconnr. nnocTissEO 

AVE 



lUO 



u 



tuo 

1U0 
lOO 
UKl 
lUO 
lUO 
lUO 

IIJ I 

lUO 
lUO 
lUO 

tuo 



J L. 



lJ L 



J L. 



-i_J l_ 



ancLE (>NE PER 'Jinv 



fiASEUNE PAJnmoNiNf; LOAD lOFNrfriEn i_ 

PAnriflONlNG TOTAL TIME FRAMC i i t ■ » 



I I t ■ « 1 I I I 1 . 1 



INDrrENPF-^JT TASK ! nAn-: 



T IMF /SI 
AVFOAGC 



xJ 



xJ 



J-J 



■JSED TO OVRT - IDE DEFAULT TASK DEF 



ON LOADING. If TASK IS ENfEnED 



VEN rr -AMETEnr: means task is to nr nnopTEn ron this PAfirtcuLAr 



as zero value 
f.valuation 



i/F D P r 

rAXMMUM 


D .r,- -NAHI TO RATES 
AVRn-Hir MAXIMUM 


riMF IIWI! PFIl rxFCUUON 
AVLnAOF MAXIMUM 


I . .... 1 


t 1 1 . ■ 1 : . : 1 1 1 1 1 1 1 r 1 1 J 


f 


I , .... 1 


Lj 1 1 1 i i-j 1 1 1 1 1 1 1 1 1 I.I 


I . 1 . I 1 1 . : 1 1 1 , . . . 1 . . . f 1 


1 . , . , 1 


1 1 1 1 i 1 l_L_l L t 1 1 1 1 1 } 


1 I , i 1 I i 1 1 . J I .... 1 .... 1 


U .1,1 


1 1 1 1 1 1 : i ■ 1^ i t 1 1 1 1 1 




1 . 1 , , . ^ 


t i t 1 1 t L ( 1 1 1 ^ 1 1 t 1 1 t 1 1 ^ f 


I 1 I i 1 f 1 , 1 t 1 t i 1 . . 1 . . . . 1 


Li_ - : > 1 . 1 1 


t 1 1 1 L 1 ^ 1 r 1 J t 1 1 I 1 1 1 I r • 1 




> ' 1 


* ' -1 1 1 r -1 • i- J I J- 1 t 1 1 1 e 1 1 1 


1 i . 1 1 i . . 1 1 if 


t 1 , , i . . . 1 


t ' ' ' ' 1 ' 1 *~i I J_l 1 i I 1 1 1 1 1 


t t ^ L 1 I 1 1 1 . J i 1 


L 1 . 1 1 r p 1 1 


i 1 » r 1 1 J lJ 1 1 1 1- 1 1 1 1 1 i 1 


Lj_j J 1 1 1 . L 1 J 1 . 1 




L_l_t _t_l J ! _L 1 i I 1 I 1 1 t I i 1 1 1 


Lj 1 1 1 i 1 1 i ■ } 1 . . . . t . . . . 1 


I t 1 t . . , , 1 


i ' ' 1 ' 1 ^-1— lJ 1 1 1 I I 1 I I I I i 


Lj^i^ i_j 1 1 1 i_ t J I . 1 . . 1 


. 1 i 1 1 • 1 1 1 1 


Lj 1 i._L 1 . 1. f J I t 1 1 1 1 t 1 1 I t 


t i 1 • i i i • i i 1 1 i 


- _L 1 ' 1 1 1 1 1 


Lj i_i 1 J-J J I J 1 1 1 1 1 1 1 1 1 











1 

,1, o X 



FVAIUATION nUN IDFNT IFlCAT ION I . . , . t , , . . j . . , , t ■ . . . I 

SPECIFIC FVALUATION FACTORS 





PnioniTY 

(CinCLE ONE) 




COMPONENT 
IDCNTIFlEn 


GOAL* UPPFR* 
LIMII 


cincte* 
coFrriciFNT 

lEVlE 


PH 


MB 


TC 




Lj_a lilt t_L_i_J 


A W 
A W 
A W 
A W 
A W 
A W 
A W 
A W 
A W 
A W 


m 


MB 


IC 




> 1 1 t 1 L 1 1 1 I i t 1 1 1 ■ 1 . , , 1 ^ 


TD 


MR 


TC 




t « ' ' I t 1 t 1 1 r 1 1 1 . . I 1 . , , 1 


PB 


MR 


TC 




^ ' ' ' ' 1 ' ' ' I > Lj— I 1 t 1 1 1 I 1 1 


re 


MB 


TC 




^ ' ' ' ' ^ t » ' « > 1 1 t 1 1 1 1 1 p 1 J 


rn 


MB 


TC 






TO 


MB 


TC 




Li 1 > t 1 1 r 1 1 J 1 1 1 1 1 1 1 1 1 1 f 


PB 


MB 


IC 




1 ' ' ' ' Li 1 1 1 1 I 1 1 1 » 1 , 1 , 1 I 


PB 


MB 


TC 


1 1 I » t 1 1 < t lJ 


Li— 1 1 1 1 1 1 1 1 1 1 1 1 • t 1 « ^ , 1 f 


PB 


MB 


TC 


* ' ' ■ ■ ^ ■ » ■ ' ' 















' IF BLANK DEFAULT IS TO GH^HAL FVALUAIION LEVEL 
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EVALUATION RUN IDGNTJflCATION 



PARTITIONING ASSIGNMENT CONSTRAINTS 



ASSIGNMENT 

TYPE 

F - FIXED 

1 - INITIAL 

P PROHIBITED 


COMPONENT 
ASSIGNMENT 
D - DATA 
T - TASK 


APPLICATION 

COMPONENT 

IDENTIFIER 


CANDIDATE 

CONFIGURATION 

COMPONENT 

IDENTIFIER VALUE IF APP. 


U 


U 


L_i__i 1 1 1 t 1 1 , I 


L.i 1 i f t > 1 1 > M . . . , 1 . , . , r 


U 


U 


L. 1 1 1 1 1 1 1 t I 1 


i_ 1 1 . . I . 1 1 , . . . 1 . ^ , J 1 


U 


U 


ill' 1 i t i 1 1 1 


L-i-J j-1 1 f 1 1 1 1 1 . . . 1 


U 


U 


L 1 1 1 1 1 1 1 » 1 1 


Ul-i 1 I . 1 I 1 1 .... I .... I 


U 


U 


1 1 1 1 1 1 1 > 1 ^ 1 




U 


U 


L_L A t 1 1 t 1 1 1 1 


1 1 1 1 1 1 > 1 ( 1 i 1 ,1 


U 


u 


1 1 1 1 1 1 1 1 1 t t 


t 1 1 . 1 1 . , I 1 1 . 1 . . 1 . 1 , , 1 


U 


u 


1 1 1 J i 1 1 1 1 1 J 


1 • I • ' 1 > • • > i 1 1 , , , 1 


u 


u 


L_i 1 J 1 1 1 1 1 , 1 


I t 1 1 t i r 1 1 1 1 I 1 . . . 1 . . . , r 



ERIC 



DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 


1 


SYSTEMS REQUIREMEHTS 
riLE ID 


RSRID 


20 Characte rs 


Used to un)queKy 
Identify system 
be 1 ng spec 6 f I ed 


2 


SYSTEM INTERFACE 
REQUIRED DEVICE 

For eoch component 










. I dani i f 1 « r 


RICID 


W characlers 


Components Identf'^ 
f ! o r to map l nt o 
candidate conf igu- 
rat 1 on component 
C IOPT-4) 




. Techno Lo^y t^ypo 


«ICTT 


2 character 
code 


Must match an entry 
In the t«^chnoLogy 
cat ei|o ry codes as 
do f 1 ned In the 
technology data 
base IOPT-3 group 2 




. Spec i f 1 c Dei/ 1 ce 
I dent 1 f 1 cat I on 


RICTD 


IB characters 


Must match to de- 
vlc«^ In technology • 
data base IOPT-5 i 
group 2 based upon 
category type 


ISSUE 


1 DATE e7-NOV-79 


ID DEALS 


SEC 


IOPT-1 PASE 1 
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ERIC 



DEALS 



CRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




.RttQulrad options 
for Inl9rfac0s 
tuharo Jc = I to numbor 
o f opt e ona for 
TarchnoLogy type 
RICTTC 1 ) 


RICOP Ck) 


Dopendei.t upon 
RIC 


Options must be 

format in techno- 
logy dota base 
I OPT -5, group. 


3 


SYSTEM DATA BLOCK/ 
BUFFER 

Fop oach data block 
.Block Idontlfier 

.Systom davic* I d«n- 

t 1 f 1 to wh 1 ch 
ass 1 gn«»d 


R5DBI 
RSOBD 








. D 1 sc 1 p 1 1 «!• 


RSDAT C I ) 


4 charocter 
coda 


Same as DEALS-IOPT5 
Group 2 master data 
discipline codes 




.Maximum Records 


RSDAT C2) 


Pos 1 t f u« 
I n t« r 






.Rocord Length 


RSDAT C3) 


Pos 1 t 1 ve 


BITS 




«B 1 ts/Cha rac t« p 




I n t«g« r 




-C|>:.racte rs/Word 


RSDAT (4) 


Pos 1 t 1 ve 
I n togo r 


Cha rac ters 


ISSUE 


I DATE 27-NOV-79 


ID DEALS 


SEC ] 


[OPT-1 PAGE 2 



1 s 



ERIC 



I 



DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUtb 


UNITS/VALUE MEANING 




1 n t mum Wo rda 


RSDAT (5) 


Pos 1 t 1 
I n t age r 


uio rds 




^Moxlmum Words 


RSOAT (6) 


Pos 1 t 1 vo 
I n taga r 


uio r ds 




^i/arago Words 


RSDAT (71 


I n tega r 


UIO r d s 


A 


SYSTEM FUNCTION 
REQUIREMENTS 

For aach function 










.Function Idf>nt9ffar 


RSF ID 


10 cho rac ta rs 






.Exocution frttquiincy' 
& timing 


RSFFQ 




TBO 




.Number of systvm 


RSFIS 


Pos 1 t 1 va 






Intarfocos sori/lcod 




Z n taga r 






by f unc 1 1 on 










.Identifier for sdch ' 
system Intarfoce j 
so rv 1 cad 


RSF I I (J) 


6 cho roc ta rs 


Must mo tch an t ry in 
RICIO (Group 2) 



ISSUE 1 DATE 27-N0V-79 ID OKALS SEC lOPT-l 
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ERIC 



DEALS 



GRP 


PARAMETER NAME 


HNEhDNIC 


VALUES 


UNITS/VALUE MEANING 




For «cich function to 
function Interface 










.InterfcJCA identi- 
fier 


RSMFI 


10 charcctors 


Must match sijstem 
block of group Z 




.Source function 
1 dent 1 f 1 o r 


RSMFS 


10 characters 


Must match entr^ in 
RSFIDC 1 ) 




.Destination func^ 
1 1 on Identifier 


RSMFD 


IflT characters 


Must match entrij in 
RSFIDt 1 ) 




. Commun l cat I on 
F requency 


RSJIFC 


Pos 1 t 1 
I n tog© r 


Records/second 

1 



ISSUE 1 DATE 27-N0V-79 ID DEALS SEC lOPT-I 



1 i J 



ERIC 



DEALS 






PARAMETER NAME 


MNEMON IC 


VALUES 


uni lo/^VAUUc. MEANING 


1 


softwa;?e job/task 

F I UE 1 0 


SWID 


c ha rdc te rs 


ZB characters max i - 
mum that idonti fy 
software definition 
fILe used for run 


Z 


GLOBAL DATA BLOCK 
DEFINITIONS 

( WOCIl OUwU DI.OCIV 












SDBIP 


IZ character 
mnemon I c 


SBID( 1 ) . NE . SDBIDC j ) 
for 1 .NE. J 




. Type 










.Description block 


SDBAT ( J ) 








at.trlbut.0 J 










-D 1 3c 1 pL 1 n« 


SDBAT ( 1 ) 


4 char, code 


same as DEALS IPT-9 
group 1 maste r data 
discipline codes 




"Maximum Records 


SDBAT (2) 


pos 1 t 1 ve 
1 n tege r 






-Record Length 










. Bl ts/character 


SDBATO) 


pos 9 1 1 ve 
t n tege r 


bl ts 
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ERIC 



DEALS 





PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




. Chd rcic t«rs/Word 


SDBATt4) 


DOS 1 1 1 ve 
1 n i ega r 


chd ror-ie r s 




.Minimum words 


SDBATC 5 ) 


PO & 1 1 1 

1 n ie g o r 


luo rd:: /reco rd 




. Max t mum luo rds 


SDBAT(6) 


po3 1 t 1 ve 
1 ntego r 


wo rda/record 




.Average uiords 


SDBAT(7) 


DOS 1 1 ; \J9 
1 nlege r 


uio rds/reco rd 


3 


TASK DEFINITIONS 
For odch ^aak 










. Tds K Identifier 


STTSI 


6 chd rcici.0 ra 






.Source Longuofse 


STSOL 


Chdrcjcler Codo 


Must mdlch mdsier 
Ldngudge list 
mainldlned in Tech- 
noLogii Ddid ddse 
DEALS IOPT-5' gro-.^ ^ 




.Inslructidn mix 
porcsmeter K for 
eocYi lnst.ructlon 
lypa J 


STIMX 







DATE 27-NOV-79 ID DEALS SEC IOPT-2 
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ERIC 



DEALS 



CRP 



PARAMETER NAME 



Iden^ I f I or 



-Count for sizing 



-Execut^lon count.s 
for 1 1 mi ng 



Ave rcsg« 



Worst case 



MNEMONIC 



STIMX 
C J . 1 ) 



STIMX 
( J .2) 



STIMX 
( J .3) 

STIMX 
( J .4 ) 



ISSUE 1 DATE 27-N0V-79 



VALUES 



IB charoctor 
c odo 



P OS 1 i 1 ve 
I n tog« r 



positive 
I ntoQe r 

pos I t I va 
I n togo r 



UNITS/VALUE MEANING 



Must motch mc3st«r 
Instruction List 
mointalned In tech- 
noLogM doto base 
DEALS IOrr-5" gr«7upj. 



10 



DEALS 



SEC IOPT-2 



PAGE 
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ERIC 



DEALS 





PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




"Oxfnr Lav F Lag 


STOLF 


Character Co do 
0 


Task rasldos on an 
ovorLay and can b« 
stored on disc uihen 
noi ttxscutin^ 




.Data storage/ 
ret.ri«vaL for each 
bLock raforenced 
bv ^asK 

"dLocK ident.! f ler 


5TDB I 


N 


Task doQs not re- 
side on on ovorLay 
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ERIC 



DEALS 



GRP 


PARAMETER NAME 


MNEnONIC 


VALUES 


Um TS/ VALUE MEAN T MR 




"Tosk ddtd storog*/ 


STDBR 








rciirlei/oL dUrlbul* 


t J , k J 








k uili^h raspsct, lo 










b Lock reco rds 










.When r«quaslod 


STDOR 


1 choract,or 








( J . 1 } 


code 










= -s- 


oLL r«cord» pro- 










cossod prior io Ihei 










buLk of processing 








= "A" 


records processod 










1 nd 1 V f duo t ti| during 










exQCutlon 








= -E " 


records processed 










uTT.an x>no DULK Of 










losk processing 




.Houf rsqu«atod 


S7DBR (2) 


1 chdractor 










cod* 










s - I - 


Input to tosk 








s -U" 


update b\i tosk(I/0) 








= -0" 


tdsk output 
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ERIC 



DEALS 



GRP 


1 

PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




.illnltnutn procoasad 




Pos 1 t 1 ve 


record3/ta3k 








7. h i.ego r 


execut t on 




.Maximum procos^ted 


ST 


Positive 


rocorda/task 








I n toga r 


exGcut 1 on 




. Ai/e rags procossed 


ST' ) 


?o s 1 1 1 ve 


reco rcJa/ tas k 








I n :.ege r 


ex ecut 1 o n 




<-Task execution 










pa ramela rs 










.Cnabtomani. type 


STXET 


4> character 










code 










B ' TIME 


time enabLed 








s 'DATA' 


data enabled 








= ' TAD ' 


time and data 










enab ted 








a ' SLVD ' 


s Laved 


ISSUE 1 DATE 27-NDV-79 


ID DEALS SEC ^ 


IOPT-2 PAGE 




ERIC 



DEAtS 



GRP PARAMETER NAME 



.Maximum T I mo Limit 
Po r Exacut I on 

BASE LINE PAR T I T I O I NG 
LOAD 

For ttach raprosen-:.a« 
tlvo baaeLine Load 
supp L V 

.BttnchmarK identi- 
fier 

.Partitioning total 
time Period 
du rat i on 



MNEMONXC 



ST iTL 



VALUES 



Pos I 1 1 Rea L 



UNITS/VALUE MEANING 



Seconds 



SLBMI 



SLBMT 



20 cha rac te I 



ISSUE 1 DATE 27-NOV-79 ID DEALS 



SEC lOPT-Z 



PAGE 



8 
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ERIC 



DEALS 





PARAMETER MAME 


MNEMON I C 


V t*t ^ u c. o 


UNXTS/^VALUE nSMffl I N<3 




.For eoch 1 dop«nd«nt. 
task 










-Id«nti f »«r 




SLITI 


6 chnracters 


Task 1 dent i f 1 er 




-Froquoncy for 
«ncib Isd or si 


i. 1 tnm 


SLITF («) 








. Av/e r age 
.Worst Ceis« 




SLITF (1) 
SLITF (2) 








-Data Arc-lval rate 
for Data anablad 


SLITD (*) 








. Ai/« r ago 




SLITD (1) 


Non-hegatl ve 
Roc L 


records per second 




.Worst Cas« 




SLITD (2) 


Hon - negat 1 %jm 


records per second 




-Maxtmum «xocut« 
1 1 me 










. Ave rage 




SLITT (I) 


Red I 


m 1 L L 1 seconds 




.Worst Casvi 




SLITT (2) 


Rea I 


m 1 1 1 1 seconds 


ISSUE 


1 DATE 27-NOV-79 


ID DEALS 


SEC 


IOPT-2 PAGE I] 



ERIC 



OrALS 





PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 


J 


EVALUATION RUN IDEN- 
TIFIERS 










.Ci/aluation run 


ETITL 


c ha r ac t e rs 


20 characters maxi- 




title 






mum for run Iden- 
t.1 7 icat.ion 




.Computation aub- 
ayatem intarfaca 
requ i rementa 
Identifier used to 
Label output and 
fetch appropriate 


ESRID 


c ha r a c t e rs 


20 characters maxi- 
mum , If blank as- 
sume value f rom 
file otheruilse per- 
form equalltii check 




system requirements 










f 1 le data 




• 






•Baseline Software 
Application task 
definitions Identi- 
fier used to label 
output and fetch 
appropriote soft- 


ESWID 


c ha ra c t e r s 


20 characters maxi- 
mum {f blank as- 
sume value from 
file otherujise per- 
form equality check 




luare task/Job defi- 










nition file data 










.Candidate architec- 
ture 1 den 1 1 f 1 e r 
used to label out- 
put and fetch ap- 
propriate candidate 
architecture file 


ECCID 


c ha rac t e rs 


20 * c ha rac te rs maxi- 
mum. If blank as- 
sume value from 
file otheruiise per- 
form equality check 




data 
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DEALS 





GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UN I TSyVAl UP MFAMTMn 






. ToohnoLogg I d«ntl - 
flflir uAsd to Ldb«L 
output and fstch 
approprlattt techno- 
Logv data 


lETDlD 


cha rac t«i ra 


20 charactar maxi- 
mum, 1 f blank as- 
sumo v.itue from 
f 1 to otheruilso p«r- 
form oquatlty check 






• BenchmfirK Load ID 


EPBMI 


H0 charactors 


Must match one of 
^tim Benchmark Load 
Identifiers In 
IOPT-2 Group 3 






•Partition ID 


EPPID 


I n t«ge r 

B 


Initial 










MPS+1 


Specific portltlon 
f rom database 

Use highest number 
partition in data 
base 



ISSUE 2 DATE 19-DEC-79 ID DEALS SEC IOPT-3 



ERIC 



DEALS 





PARAMETER NAME 


nNc. nUN 1 U 


VALUE S 


UNITS/VALUE MEANING 


Z 


GLOBAL EVAULATION 










FACTORS 










.For eoch proidefined 










priori tM l9%jml I =1 










to 3 










'Objectli/o Lei/eL to 


EFPLDt 1 ) 


Pos 1 t 1 






bo OSS 1 0n«d I f 




Intogors0. 1 .Z.3 






zaro objectli/e I 










Is not app L I cob Le 


EFPLD (1) 




LttvoL for processor 










ut 1 L 1 zo 1 1 on 






EFPLD (Z) 




LsvsL for memory 










o L Loco 1 1 on 






EFPLD (3) 




LovA'L for dttv«top- 










man t cost 


ISSUE 


Z DATE 19-DEC-79 


ID DEALS 


SEC 


IOPT-3 PAGE 




\ 


12i 





ERIC 



DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




. D« i/ti Lopma n i. coat, 
goo I 


EFDCG 


f la.z 


Mon Hours 




• OawLopmont cost 
uppo r Limit 


EFCCU 


F10.2 EFDCU.GE. 
EFDCG 


Man Hours 




• Boslc unap«»clf|«d 
0ooL parcontoge for 
memory, utILIiiotlon 


EFMUB 


H.LT.EFMUB.LT. 
1 .0 


"AMcmory utILizotion 
thot ui 1 L L provrlda 
daslrad atoroga 
groujth boLonce 




•Memory utiLlzotlon 
uppo r Limit 


EFMUU 


EFMUB. LE . EFMUU 
. LE . 1 


%Ut 1 L 1 zot 1 on 




.Boslc unspaclflad 
gooL percantogo for 
procassor utiLlzo- 
tlon 


EFPUB 


0.LT.EFPUB .LT. 
1 .0 


*A Procassor utiLlzo- 
tlon thot lUlLL 
p rov Ida daslrad 
utiLlzotlon 
ba Lon ca 




•Procassor utlLlzo- 
1 1 on uppar Limit 


EFPUU 


EFPUU ,GE . EFPUB 


%Ut 1 L 1 zot 1 on 




•Procassad dafouLt 
coafflclani Lai/aL 

.Mamor^ dafouLt co- 
a f f 1 c I a?) t Lava L 

•Tosk dafouLt co- 
o f f 1 c 1 an t Lave L 


EFDCL (I) 
EFDCL (2) 
EFDCL (L3) 


choroctar coda 
= • A' 

= • w 

choroctar codo 
= • A' 
2 • W 

chdrocter coda 
a 'A' 


Ava roga 
Wo r s t cos a 

Ava roga 
Worst Cdsa 

Av« roga 
Worst Casa 


ISSUE 


2 DATE 19-DEC-79 


!D DEALS 


SEC 

JL 


IOPT-3 PAGE 



ERIC 



DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


3 


SPECIFIC EVALUATION 








FACTORS 








SttLeci,l\/e goal 1 
















-Goal iMDo tdenif-* 


EFCUSC 1.1} 


2 character 




f 1 o r 




c ode 








= ' PB • 








= 'MC 








= * TC * 




-Compon«nt Identt- 


EFCUS(2. 1 ) 


10 characters 




f 1 0r 








-Solactlc^e goal to 


EFCUSC3. 1 ) 


0.LT.EFCUS(3. 1 ) 




bo ut 1 1 1 zed for 




.LT. 1.0 for 




component i 




EFCUSC 1 . M e 








'PU' or 'MM' 








EFCUSO. 1 ) .GT . 








0 for EFCUS 








( 1 . 1 ) s ' TC • 



UNITS/VALUE MEANING 



Proceaaor utiliza- 
tion ba lance 

Memory utilization 
ba lance 

Task development 
cost 

Must match memory 
of p rocesso r 
component identi- 
fier in IOPT-4 

%Ut I 1 1 zat ion de- 
sired for processor 
and memory compo- 
n e n t s 

M a ny ea r^ 



DATE 19-DEC-79 



ID DEALS 



SEC lOPT-3 



PAGE 



ERIC 



DFALS 



GRP 



PARAMETER NAME 



Limit goo L to be 
utiLizttd for com- 
po no n t I 

-SeLectli/e coeffi- 
cient Levre L 



MNEMONIC 



3 



ErCUS(4 , I ) 



EFCUStS. I ) 



VALUES 



Same oa 
EFCUSt3. I ) 



1 c ha roc te r 
code 



UNXTS/VALUE MEANING 



s 'A' 
= 'W 



Ave ro ge 
Worst case 



ISSUE 



DATE 



27-N0V-79 



ID 



DEALS 
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SEC IOPT-3 



PAGE 



ERIC 



DEALS 





PARAMETER NAME 


MNEMDN IC 


VALUES 


UNITS/VALUE MEANING 


4 


PARTITIONING ASSIGN- 
MENT CONSTRAINTS 

For each conalralni 

.Partition Map 


EPMAPt 








-Typ© rostriction 


EPMAPC I ) 


character code 

F 

I 

P 


F 1 xed a L Locat 1 on 

INltlaL aLLncaf inn 

Prohibited aLLoca- 
1 1 on 




-Task or data 
Ass Ignment Flag 


EPMAP(2) 


T 
B 


Task 
Block 




-Task or data block 
1 dent 1 f i • r 


EPMAPO) 


6 c ha rac te rs 
10 characters 


Must match base t I ne 
software task Iden- 
1 1 f 1 er If EPMAP(2) 
B ' T ' 

Must match baseline 
software data block 
Identifier if 
EPMAPO) a 




-Component identi- 
fier 


EPMAPO) 


10 characters 


Must match a candi- 
date compo n e n t 
( IOPT-4 Group 2 ) 
Identifier or re-^ 
quired component 
( IOPT-1 group 2) 



DATE 27-NDV-79 ID DEALS sEC rOPT-3 
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ERIC 



DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 


S 


SELECTIVE COEFFI- 
CIENTS 

*SeLectli/e Coeffi- 
cient LeuaLa may 
ovsrrlde specific 
technology compo- 
nent attribute 


ESTPR («) 








. Component I den 1 1 - 
f 1 e r 


ESTPRC I ) 


10 characters 


Must match compo- 
nent Identifier in 
IOPT-4 




.Attribute index 


ESTPRCZ) 








.Coefficient Lei/eL 
for Att r 1 bu te 


ESTPRO) 


character code/ 
same ds for 
t UT r K 




1 


.Coefficient Lei/eL 
se tec t 1 ons 










-Softuiare Load at- 
tribute Loi/eL to 
be ESLPR used in 
coefficient deter- 
m 1 n a 1 1 ons 


ESLPR 


Character code/ 
A 

W 


Average numbers to 
be app Lied 
Worst case number 
to be app Lied 


ISSUE 


DATE 27-N0V-79 


ID DEALS 


-4 SEC 

1 z (J 


IOPT-3 PAGE 8 



ERIC 



DEALS 



CO 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




-Basic unspecified 
technology attri- 
bute leuoL to be 
used in coef- 
ficient determl- 
n o 1 1 o n s 


EUTPR 


Character code/ 
A 

W 


Auerage numbers to 
be a p p L 1 e.d 
Worst case numbers 
to be app Lied 



I5SUE DATE 27-N0V-79 ID DEALS SEC rOPT-3 



1 9 ^ 

-L *w I 



ERIC 



DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 


1 


CANDIDATE CDNFIBURA- 
TIDN DEFINITION 










Condldoto Idantlfioir 


CCID 


c h ct r d c t. o r s 


MdximuM of 20 char- 
dctor3 uihlch ar« 
ii3ed to Idbttl dnd 
ldontlf%| cdndlddt,« 
d re h 1 t,«ct,u rm 
d« f t n«d 


Z 


CANDIDATE DEVICE 
OEF INITION 

For ecjch component, 
de V 1 c e 










. Id«ni 1 f 1 or 


CCCID 


10 c ha ract,« r« 


Cdndlddto Componsnt 
I dsn 1 1 f 1 r 




oTechnoLogg t,(|p« 


CCCTT 


2 chdraci^er 
cod* 


Must, mdt^ch dn •nlry 
In t,he technolog\| 
cdtogory codes as 
do f 1 ned in the 
technoLogij data 
base IOPT-3 group 2 




. Sn«c 1 f 1 c d«i/ 1 ce 
t dent 1 f 1 cot I on 


CCCSD 


10 charact^ors 


Must match to de- 
vice In tochnoLogij 
data base lOPT-S 
group 2 based upon 
categorvf type 



DATE 27-N0V-79 ID DEALS SEC IOPT-4 



ERIC 



DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




.SsLect^ed opinion k 
for component 


CCCOPt Jc ) 




Supplied options 
are dependent upon 
specific component 
and correlate tuith 
appropriate tvipe/ 
Identifier options 
in techology data 
base IOPT-3 group Z 



ISSUE 1 DATE 27-N0V-79 ID DEALS SEC IOPT-4 PAGE 
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ERIC 



DEALS 



CRP 



PARAMETER NAME 



TECHNOLDCY FILE IDEN- 
TIFIER 

MASTER TECHNDLDGY 
LISTS MASTER GATE- 
GDRY LIST 

Numbe r of currsnt 

CO tttOO r I Q3 

For eoch cai^ttgorxj 
1=1 to TCNC 

.Cotegorij ld«ntlfi«r 



Th« first thrett a r« 
the primory areas 
r«qulred for soft* 
wore poritaoning. 
The others represent 
sources or destina- 
tion for processing 
I/O ond only require 
as a minimum respec- 
tive I/D transfer 
rates, blocking, and 
protocol interface. 
Category IS labeled 
black box Is a catch 
all category, Dther 



ISSUE 



DATE 



27-NDV-79 



MNEMDNIC 



TDBID 



TCNC 



TCCI ( I ) 



TCCI ( 1 ) 
TCCI (2) 

TCCI C3) 
TCCI C4) 

TCCI C5) 

TCCI C6) 
TCCI C7) 
TCCI CB) 
TCCI t9) 
TCCI ( 10) 



VALUES 



20 Characte rs 



Pos f 1 1 ve 
I n tege rs 14 



2 character 
c ode 

PU 
CL 

MM 
CP 

CC 

KB 
DP 
MB 
GE 
IC 



UNITS/VALUE MEANING 



To n tat I ve List 
I n c I udea x 

Bproceaaor unit 
scommun I cat I on llni 

(vole e/da ta ) 
= memo ry 

=cockplt inatrumen- 
tat I on pane Is 

^cockpit controls/ 
sujl tches 

= keyboa rd/te le type 

s d I s p lay 

^mo 1 1 o n base 

« " g " equ I pme n t 

= I n s t rue to r/ope ro- 
tor control aujlt- 
ches 



ID 



DEALS 



SEC IDPT-3 



PAGE 



ERIC 



DEALS 



GRP 


PARAME TE R NAMr 


nNtnuM 


VALUES 


UNITS/VALUE MEANING 




cai.«gori«.s can bo 
addod. The Par^icu~ 


TCCI (11) 


CM 


■ 

"TV Camera/Model 

boa rd 




lar design ei/dlua- 


TCCI ( 12) 


PR 


sP r 1 n te r 




tlon environment 


TCCI ( 13) 


CR 


eCa rd reader 




must be cansldtired 


TCCI ( 14) 


BB 


sBlack box 




as to uihot cotego- 










ries and lei/el of 










data needs to be 










CO L Lected . 










MASTER DEVICE LIST 










FOR CATEGORY i 










.Number of dei/lces 


TCND( 1 ) 


Non nega 1 1 ve 






of catego ry i 




1 n t ege r 






currently In tech- 










nology data base 










. Dev Ice list (for 
catego ry I ) of 
device Identifiers 

J = 1 to TCND( 1 ) 


TCDL(.I .J) 


10 characters 


Each entry must be 
un 1 que within the 
List for given 
category i 




MASTER INSTRUCTION 










LIST 










.Number of benchmark 


TCN.T 


pos 1 t 1 vo 






1 ns t rue 1 1 ons 




1 ntego r 






.Instruction 1. 1st 
for Instruction lal 
to TCNI 


TC1L( 1 ) 


10 character 
code 


TCIL( 1 ) not equal 
TCIL(J) for 1 
not equal j 
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ERIC 



DEALS 



GRR 


PAi^AMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE .LEANING 




MASTER BLOCK DISCIP- 
LINES 










• Number of disclp'* 
L t na3 


TCNBD 


po s 1 1 1 %jm 
I n togci re7 






.List of dl3clpLin« 
keya for 1 « 1 to 
TCNBD in oLphd- 
nutn«rlc ordar 


TCBDLC 1 ) 

TCBDL ( 1 ) 
TCBDL(2) 
TCBDLC 3) 
TCBDL(4) 
TCBDLC 3) 
TCBDLC 6) 

TCBDLC 7) 


4 chdrdctar 

codes 

= • CBUF • 

= • F IFD • 

»*LIFD' 

e • RAN • 

« • RDR • 

a • ROS • 

= 'SEQ • 


circuLdr buffor 

qucuQ 

s tdck 

rdndom I/D 
radd onLy rdndotn 
radd onLy soquan* 
t 1 d L 

3 aduan 1 1 d L I /O 




MASTER BLDCK TYPES 










. Numb* r of t VP* A 


TCNBT 


pos 1 t 1 

1 niega reS 




1 


• List of bLocK itip« 
keys for 1 « 1 to 
TCNBT In oLpho- 
nutneric ordar 


TCBTLC 1 ) 

TCBTLC 1 ) 
TCBTLCZ) 
TCBTLC3) 
TCBTLC4) 
TCBTLC 5 ) 


i chcsraclar 
cod« 
s 'G • 
e • I • 

8 • L • 
a 'S • 
a • T • 


gLobd L 

1 ns t rucl 1 on3 

Locd L 

3 lam 
lampdrdry or 
so rd tch 


XSSU£ 


1 DATE Z7-NDy-79 


10 DEALS 


SEC 

132 


lOPT-S PAGE 3 



ERIC 



DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




MASTER DEVELOPMENT 
SOURCE LANGUAGES 










•Number of Languages 


TCNL 


POS { t 1 \J9 

I nlege r 






•List of Languag* 
Keys for I s 1 to 
TCNL in alphn- 
numericaL order 

1 


TCLL ( 1 ) 


10 characters 




3 


PROCESSOR ATTRIBUTES 
FOR EACH PROCESSOR P 

Operoting Sgstevn 
F «a t.u ro3 

. Mu L 1 1 task 1 ng 










-Lev* L« 


TPOSM( p, 1 ) 


Integer . GE . 1 


Number of distinct 
task execution 
Leve Is 
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DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




- Numb* r of priority 
3 e r\j i CO Le\/e Ls 


TPOSM( p ,2) 


Integer 

.GE . 0 

. LE . TPOSMt p , 1 ) 


The remaining TPOSM 
( p , 1 ) -TPOSM( p , H ) 
LeveL3 are assumed 
to bo serv/lce in a 
circular fashions 




. E nab Lvmsn ts 










-Max 1 mum T Ima 
•nabLement fr«- 


TP0SMrp,3) 


Integer 


Enabtements/second 




q ue n c y 










"Resource manage- 
me nt Pmr t\ mm 
enab Lemeni. 


TP0SM(p,4) 


F10.9 .GE, 0 


Seconds accurate 
to Nano seconds 




'Maximum data 
enabLemeni. fre- 


TP0SM(p,3) 


I n tege r 


Enab Lemen ts/s econd 




quency 










'Resource manage- 
men t per dato 
enab Lome n i. 


TP0SM(P.6) • 


F10.9 .GE, 0 


Seconds accurote to 
Nano seconds 




"Maximum sLai/ed 
enablement fre- 


TPOSMCp.7) 


Integer 


Enab Leme ri ts/s econd 




quer^cij 










-Reaourt^e manage- 
ment per sLai/ed 
e ndb Lemerni 


TPOSMC p . 8 ) 


F10.9 ,GE. 0 


Seconds e^curate 
to Nano seconds 
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DEALS 





GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 






-Rasourco manag*- 
ment ovarhead per 
socond par i,asR 


TPOSMC P , 9 J 


F10.9 .GE. 0 


Seconds accurate to 
Nanb seconds 






.For each task Level 
L=l to TP0SM(p,2) 












-Maximum number of 
tasks Le^/eL L 


TPOLT 
(p. I. 1 ) 


I n tege r . QE . 1 








^Taak se rv 1 ce 
scheme for Lei/oL L 


TPOLS 
(p. 1.2) 


Code 




o 








s • c* 
c • F • 


Priority 
C 1 rcu la r 

F 1 rs t in f 1 rs t out 






.Level- resource 
management 


TPOLM 
CP. 1.3) 


FIB. 9 .GE.B 


Seconds accurate to 
Nano seconds 






.List of compatible 
use r memo r I es 












Simulation instruct 
tlon set measurements 
for each benchmark 
1 ns t rue t Ion i 












.Sizing measurements 












"Number of code 
memo riea Involved 


TPSCMtp. 1 ) 
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DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




The memory tvp« ^or 
•och codtt memory m 
( th« first memory is 
the user tdsK code-- 
ony other memories 
ore predefined for 
this processor) 


TPSMT 
( p • 1 • m ) 


4' c ha rac te r 
code 




Must ag ree tul th 
master memory 
types defined In 
Group 4 




-Length of code In 
memory m 


TPSMT 

( p , 1 p m. 3 ) 


I n tege r 


. GE . 


1 


Numbo r of basis 
un 1 ts used to 
des 1 rbe memory m 
(see Group 4 ) 




.Timing Meosurements 
for each code 

memory m and ksl,2 










k°l Ifriplles average 
ks2 Implies worst 
case 




-Number of instruc- 
tion of scratch 
data fetch uia 1 ts 


TPTM 
tp, 1 ,m, 
1 . k } 


I n tege r 


.GE . 


0 






-Number of scratch 
data store uiaits 


TPTM 
t P , 1 . m. 
2, k ) 


I ntego r 


.GE . 








-Computa 1 1 ona L 
total for all 
memo r 1 es 


TPTT 
(P. 1 .k) 


X n t ege r 


.GE . 


0 


Cyc los 



ISSUE I DATE 14-AUG-79 ID DEALS SEC lOPT-5 PAGE 7 



DEALS 



GRP 



PARAMETER NAME 



HNEnONlC 



VALUES 



UNI YS/VALUE MEANING 



.AppLicotlon d«vtt«* 
Loponttnt m«oaur«m«nLs 
U2&lng Longuoga L of 
tha inoaler Longuogti 
List 

^Dn« time davoLop- 
mont charge 

-Change per appli- 
cation BnAtructlon 
of this type 

COnnUNICATION LINE 
ATTRIBUTES 



MEMORY ATTRIBUTES FOR 
MEMORY DEVICE M 



Type 



TPDC 

(p. I . 1 » L) 
TPDC 

C P » I , 2 p L ) 



TMTPCm) 



Integer 



I n tego r 



A c ha reset* rs 
« ' ROM • 
a * RAMM ' 

« * RRAM ' 

8 'SM' 



Monhou r3 



Man hau r 3 



To be de f I ned I n 
Multiple processor 
commun I cat I on 
aha Lys I s tosk 



Read onlg memory 

Random access main 
memo ry 

Ratat.lng random 
access memo ry 

Sequentlctl memory 
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DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 








e • WCS • 


WritobLe Control 
Sto re 




Number of dlfferonl 
oddrvssdbLo unlt.3 


TMNAU 


Pos 1 t 1 

I n tQ0« r 






S 1 z« 1 n b 1 is 










.Mm 


TMSHCm. 1 ) 


P O 3 1 t 1 O 

1 n t«0e r 


bits 




. Max 


TMSHCm, 2) 


pos 1 t 1 V0 

Integer 


b 1 ts 




. I nc rsmcnia 


TMSHCm. 3) 


pos 1 t 1 
1 n tetfe r 


b 1 ts 




For •cjch oddessoblo 
unit ual to TMNAU 


TMAUP 
(m. u , 1 ) 


4 chorcicter 
code 

= 'BIT • 

s '6BB' 

= • 8BB ' 

s'WORD' 
a 'HWRD' 

= 'DBWD* 

■ 


bit dddressoble 
six bit byte 

dddressoble 
•Ight bit byte 

d dd r essdb I e 
word dddressdble 
half word 

dddressdb le 
doub lewo r d 

odd ress ob le 
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DEALS 



GRP 


PARAMETER NAME 


MNEMONIC 


VALUES 


UNITS/VALUE MEANING 




.Bits/unit LttViiL 


TMAUP 
(m.u.Z) 


p09 1 t 1 va 
1 n taga r 


axcLusii/a of partt<^ 
or arror daLatlon 




. Radd CJCCV33 i^lme 


TMAUP 
( m^ u , 3 ) 


raa L 


Seconds accurate to 
nano -seconds 




.Read cycLatlme per 
unit 


TMAUP 
( m , u , 4 } 


rad L 


Seconds accurate to 
nano-seconds 




.Maximum s«qu«ni.lat 
units tranafarrsd 
for 31 ng La raad 


TMAUP 
( m , u , 9 ) 


pos 1 t 1 va 
1 ntaga r 


same OS unit LavaL 




.Wrlta occas 1 1 ma 


TMAUP 
( m , u , 6 ) 


raa L 


Seconds occurate to 
nano-seconds 




.wi i^a cv^^ai^ima/^ 
un 1 t 


TMAUP 
(m.u.7) 


raa L 


Seconds occurate to 
nono'saconds 




•Max sequantlaL 
units for 3l ng La 
uir 1 ta accasa 


TMAUP 
( m , u , 8) 


pos 1 t 1 va 
I ntaga r 


same as unit LaveL 




.Error da taction/ 
cor rac 1 1 on 


TMAUP 
(m, u, 9) 


6 charactar 
coda 

s ' PARITY • 

a 'SECDED' 


parity bit 

s 1 ng Le bit a r ro r 
CO r rac t ion 
doubLa bit arror 
detect 1 o n 
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DEALS 



GRP 


PARAMETER NAME 


MNEnONIC 


VALUES 


UNITS/VALUE MEANING 




Number of SuppLS^ra 
for oach suppLlor 


TPMNSCm? 


poa 1 i 1 vo 
1 niogo r 






. Idoht 1 f 1 ttr 


TPMSP 


10 choroc^vha 


uiii»]uw icmnwi fior 




.MTBF 




ro o L 


hours-msdn iimo 
boirUioon fdlLuroa 




. MTTR 


T* B M O B 

TrMSP 
(m, 4 , 3) 


red L 


houra-msdn time to 
ropa 1 r 




• MSPM 


T rnfiir 
(vn. 3 ,4) 


rod L 


hours -roachoduLod 
prouohtdtiuo moint.- 
• hdhco 




.MTPM 


TPMSP 
( m , a , 9 ) 


rod L 


hours-modh time for 
preuohtdtivo maint''- 
onanc* 


6 


COCKPIT INSTRUMENTA- 
TION PANEL ATTRIBUTES 








7 


COCKPIT CONTROLS/ 
SWITCHES 








8 


KEYBOARO/TELETYPE 
ATTRIBUTES 








9 


OISPLAY ATTRIBUTES 









ISSUE 1 



OATE 6-AUG-79 



ID DEALS 



1^0 



SEC lOPT-3 



PAGE 



1 1 



EKLC 



DEALS 



l»K r 


DADAMCTITD MAMlP 


i<i u c Mn T ^ 

riNEnoN 1 c 


VALUES 


UN I TS/VALUE MEAN I NG 


10 


MOT Z ON BASe ATTRI- 
BUTES 








1 1 


"G- EQUIPhENT ATTRI- 
BUTES 








12 


I NSTRUCTOR/OPERATOR 
CONTROL/SWITCH ATTRI- 
BUTES 








13 


TV CAflERA/hOOEL BOARD 
ATTRIBUTES 






• 


14 


PRINTER ATTRIBUTES 








19 


CARD READER ATTRI- 
BUTES 








1 6 


GENERIC BLACKBOX 
ATTRIBUTES 
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»nH:MM:SS EVALUATION CANDIDATE PASS PAGE ? 



SYSTEM TECHNOLOGY 



H 

. C 

I/) 

m 

FORMAT!. STANDARD RUN IDENTIFICATION rn 

0 

I 

0 

m 
0 



ERIC 



HARDWARE COMPONENT SUMMARY 

CATEGORY/DEVICE ID REQUIRED 

XX XXXXXXXXXX XXXXXXXXXX XXX 
XX XXXXXXXXXX XXXXXXXXXX XXX 
XX XXXXXXXXXX XXXXXXXXXX XXX 

*** TOTAL NUMBER OF COMPONENTS = 9999 

FORMAT 2. HARDWARE COMPONENT SUMMARY 



14o 



DATA BLOCK SU^WARY AND EXTERNAL SOURCE/DESTINATION 



LEVEL DISCIPLINE MAXIMUM BITS/ 
BLOCK IDENTIFIER -FLAG -FLAG RECORDS BYTE 



909 XXXXXXXXXX X-XX XXXX-XX 999999 9 

999 XXXXXXXXXX X-XX XXXX-XX 999999 9 



BYTES/ WORDS-PER-RECORD 
WORD AVE MIN MAX 



99 9999 9999 9999 
99 9999 9999 9999 



EXTERNAL COMPONENT 
BASIC SPEC FREQUENCY 



XXXXXX 999 
XXXXXX 999 



999 
999 



FORMAT 3. DATA BLOCK SUMMARY 
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TASK SUMMARY 



INPUT OUTPUT ENABLEMENT FREO FRFn fufo 
TASK IDENTIFIER LANGUAGE BLOCKS BLOCKS DISCIPLINE 1 2 3 

99 XXXXXX XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX XXXX 9999 9999 9999 

XXXXXXXXXX 

99 XXXXXX XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX XXXX 9999 9999 9999 

XXXXXXXXXX XXXXXXXXXX 

XXXXXXXXXX XXXXXXXXXX 



FORMAT 4. TASK SUMMARY 
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BASELINE LOAD SUMMARY 



BASELINE LOAD XXXXXXXXXXXXXXXXXXXX 
PARTITIONING TOTAL TIMEFRAME 9999999999 

TIME/SLAVED RATE 
TASK ENABLEMENTS/SECOND 
ID AVERAGE MAXIMUM 



DATA ENABLED RATE 
ENABLEMENTS/SECOND 
AVERAGE MINIMUM 



TIME LIMIT PER EXECUTION 

MILLISECONDS 
AVERAGE MAXIMUM 



9999999999 9999999999 
9999999999 9999999999 
9999999999 9999999999 



9999999999 9999999999 
9999999999 9999999999 
9999999999 9999999999 



9.99999999E+99 9.99999999E+99 
9.99999999E+99 9.99999999E+99 
9.99999999E+59 9.99999999E+99 



FORMAT 5. BASELINE LOAD SUMMARY 
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EVALUATION ASSIGNMENT CONSTRAINTS 



ASSIGNMENT 
TYPE* 

XXXXXXXXXX 

XXXXXXXXXX 

XXXXXXXXXX 



*( FIXED 

{prohibited! 
(initial 



APPLICATION 
COMPONENT COMPONENT 
ASSIGNED** IDENTIFIER 



** 



xxxx 
xxxx 
xxxx 



(dataI 

j TASK j 



XXXXXXXXXX 
XXXXXXXXXX 
XXXXXXXXXX 



CONFIGURATION 
COMPONENT 
IDENTIFIER 

ON XXXXXXXXXX 

ON XXXXXXXXXX 

ON XXXXXXXXXX 



VALUE 
WHEN 
APPLICABLE 

XXXXXXXXXX 

XXXXXXXXXX 

XXXXXXXXXX 



FORMAT 6. EVALUATION ASSIGNMENT CONSTRAINTS 
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EVALUATION PRIORITIES 



-MAJOR PRIORITIES- 



. . GOAL/ 
LEVEL PRIORITY IDENTIFIER/ TOLERANCE 
UNITS 



COEFFICIENT 
LEVEL & 
MAX ITER 



PRIORITY COMPONENTS- 
COMPONENT GOAL 



TOLERANCE 
PERCENT 



9 XXXXXXXXXXXXXXXXXXXX 99999.99 
XXXXXXXXXX 99.999 



9999 



XXXXXXXXXX 



99999.99 



99.999 



9 XXXXXXXXXXXXXXXXXXXX 99999.99 
XXXXXXXXXX 99.999 



9999 



XXXXXXXXXX 



99999.99 



99.999 



9 XXXXXXXXXXXXXXXXXXXX 99999 99 
XXXXXXXXXX 99.*999 



9999 



XXXXXXXXXX 

XXXXXXXXXX 
XXXXXXXXXX 
XXXXXXXXXX 



99999.99 

99999.99 
99999.99 
99999.99 



99.999 

99.999 
99.999 
99.999 



FORMAT 7. EVALUATION PRIORITIES 
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BASIC PARTITIONING PROBLEM SIZE 
999 TASKS . 99 PROCESSORS 

999 DATA BLOCKS 99 MEMORIES 
9 PRIORITIES SELECTED 



FORMAT 8. BASIC PARTITIONING PROBLEM SIZE 



151 



PRIORITY GOAL SUMMARY 



-MAJOR PRIORITIES- 



-PRIORITY COMPONENTS- 



LEVEL 



GOAL/ 

PRIORITY IDENTIFIER/ TOLERANCE 
UNITS 



CURRENT 
ACHIEVEMENT/ 
LEV/FLAG COMPONENT 



GOAL 



CURRENT 
TOLERANCE ACHIEVEMENT 
PERCENT LEVEL FLAG 



XXXXXXXXXXXXXXXXXXXX 99999.99 
XXXXXXXXXX 99.999 



XXXXXXXXXXXXXXXXXXXX 
XXXXXXXXXX 



XXXXXXXXXXXXXXXXXXXX 
XXXXXXXXXX 



99999.99 
99.999 



99999.99 
99.999 



99999.99 
FF 



99999.99 
FF 



99999.99 
FF 



XXXXXXXXXX 99999.99 99.999 9999.99 FF 

XXXXXXXXXX 99999.99 99.999 9999.99 FF 

XXXXXXXXXX 99999.99 99.999 9999.99 FF 

XXXXXXXXXX 99999.99 . 99.999 9999.99 FF 

XXXXXXXXXX 99999.99 99.999 9999.99 FF 

XXXXXXXXXX 99999.99 99.999 9999.99 FF 



TO 
CO 

O 



O 

CO 



XXXXXXXXXX 
XXXXXXXXXX 
XXXXXXXXXX 



99999.99 
99999.99 
99999.99 



FORMAT 101. PRIORITY GOAL SUMMARY 



52 



99.999 9999.99 FF 
99.999 9999.99 FF 
99.999 9999.99 FF 



m 

CO 



EKLC 



TASK ALLOCATION 



TOTAL 

TASK PROCESSOR EXECUTIONS TIME FL 
XXXXXX XXXXXXXXXX 999/999 9.99999 FF 

XXXXXXXXXX 999/999 9.99999 FF 

mxxx XXXXXXXXXX 999/999 9.99999 ff 



FORMAT 102. 



TASK I/O 



BLOCi: 


MEMORY 


INPUT 


OUTPUT 


XXXXXX 


XXXXXXXXXX 


9.999999 


9.999999 


XXXXXX 


XXXXXXXXXX 


9.999999 


9.999999 


XXXXXX 


XXXXXXXXXX 


9.999999 


9.999999 


XXXXXX 


XXXXXXXXXX 


9.999999 


9.999999 


XXXXXX 


XXXXXXXXXX 


9.999999 


9.999999 


XXXXXX 


XXXXXXXXXX 


9.999999 


9.999999 


XXXXXX 


XXXXXXXXXX 


9.999999 


9.999999 


XXXXXX 


XXXXXXXXXX 


9.999999 


9.999999 



ALLOCATION 




ERIC 



DATA BLOCK kimim 



BLOCK MEMORY LENGTH PERCENT PROCESSOR STORES FETCHES TOTAL 



99.99 immm mm 999999 9999999 



999999 999999 9999999 
999999 99.99 mmUU 999999 999999 9999999 

99.99 mmmi mm mm 9999999 



FORMAT 103. DATA BLOCK ALLOCATION 



PROCESSOR ALLOCATION 



PROCESSOR UTILIZATION 



PROCESSOR 
XXXXXXXXXX 



TASK 


EXECUTIONS 


COMPUTATIONAL 


INPUT/OUTPUT 


RESOURCE MGMT 


FLAG 






TIME 


PERCENT 


TIME 


PERCENT 


TIME 


PERCENT 




XXXXXXXXXX 


999 


9.9999 


99.99 


9.9999 


99.99 


9.9999 


99.99 


FF 


XXXXXXXXXX 


999 


9.9999 


99.99 


9.9999 


99.99 


9.9999 


99.99 


FF 


XXXXXXXXXX 


999 


9.9999 


99.99 


9.9999 


99.99 


9.9999 


99.99 


FF 


**TOTAL** 


99999 


99.9999 


99.99 


9.9999 


99.99 


9.9999 


99.99 


FF 



FORMAT 104. PROCESSOR ALLOCATION 
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mm ALLOCATION 



WENORy BLOCK LENGTH 

immm mimm mm 
mmmi mm 

**TOTAL 993399 

M 

Ul 

M 



PERCENT PROCESSOR STORES 

99.99 immm mm 

99.99 immm mm 

mmmi mm 

99,99 mmmi mm 

immm mm 

**TOT PROC 9999999 
FORMAT 105. MEMORY ALLOCATION 



FETCHES TOTAL FLAG 

999999 9999999 FF 

999999 9999999 FF 

999999 9999999 FF 

999999 9999999 FF 

999999 9999999 FF 

9999999 99999999 FF 
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